UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> Web Services Dll Created For Access App Is Missing The App.config File, Access 2010    
 
   
colelaus
post Apr 20 2017, 08:46 PM
Post#1



Posts: 1
Joined: 20-April 17



I've been asked to push some data to an external web service using Access 2010. After researching this all day, it looks like many suggestions point to using Visual Studio to create a dll that utilizes VS's ability to auto generate the web services protocol code, reference then dll in Access and then call it from my Access 2010 database. The web service code works great as a standalone exe. However, when I create a dll, reference it within Access and then call it from by Access VBA code, I get the following error
"Could not find the default endpoint element that references contract 'ServiceReference1.NameOfMyDllClass' in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this contract could be found in the client element."

After a little more digging, it appears that creating a dll does not include the app.config file that contains this information so I'm guessing my class can't find the configuration information it needs. Most recommendation indicate the add the info in the app.config file to the host's app.config but off course Access does not have anything like that.

With so many recommendations to use dlls that wrap the web services, it sounds like a great way to go but I must be doing something wrong. Any help to get me pointed in the right direction would be appreciated.
Go to the top of the page
 
jleach
post Apr 22 2017, 05:55 AM
Post#2


UtterAccess Editor
Posts: 9,686
Joined: 7-December 09
From: Staten Island, NY, USA


A dll is a code library. The .config files go along with the executable entry points, not the code library itself. When you load a dll, it is loaded into a sort of execution context (e.g., who called it, what process it's attached to), and that execution context should be providing any configuration values as may be required. In the case of using a dll without Access, Access is the executable that hosts the dll context. Whatever values your .NET program might be passing to the dll, your Access program will need to as well (you said it works as a standalone EXE, so presumably you have a console application or something in the .NET solution?)

With that said, I'm curious why you felt the need to drop into a .NET. What type of web service are you working with?

--------------------
Go to the top of the page
 
AlbertKallal
post Yesterday, 08:00 PM
Post#3


UtterAccess VIP
Posts: 2,463
Joined: 12-April 07
From: Edmonton, Alberta Canada


Might have been me recommending to use .net when consuming web services from Access.

The GREAT reason for this is if the web service provides a web definition (WSDL), then you JUST point your .net project to that WSDL and like magic all of the properties and methods of that web site are like “magic” written for you. It truly is the cat’s meow. For any web service beyond a “simple” get/post, then I high recommend using .net to build all of the pluming for you. You never even look at or care about the XML shuffled back and forth.

So if the web service in question does have a WSDL, then go for it! You avoid hand coding xml, you avoid parsing out the returned data, and you get to code with inteli-sense. This approach is BY FAR the easiest approach and LEAST amount of work to consume a web service. If you ever added a web service to a .net project, you know the magic I am talking about!

However, a few issues crop up, and in your case it is WHEN you decide to move from an .exe (.net) to a .dll. Of course creating a dll (COM object) is .net REALLY is quite much is the requirement to consume such code from Access.

So for the last 30+ years, when we create a dll your usually talking about a hunk of code and is “most” cases we talking about building a “class” as opposed to a “.exe”.

You are 100% correct that if you take a simple .exe program, then the .net program WILL load the config file (in this case your config file has ALL OF that magic web services defines and those so called “end points”).

There is an “easy” solution to this issue.

So lets take a bit of simple .net code (a .exe) file.

We have this simple .exe (console) application:

CODE
Module Module1
    Sub Main()

        ShowSet1()

    End Sub

    Public Sub ShowSet1()

        MsgBox("Setting of setting1 = " & My.Settings.Setting1)


    End Sub

End Module


The above reads the config file and displays a value. Ok, so we compile this application into a .exe and you get this:

CODE
Test2.exe
Test2.exe.config


So in the above case (or your .exe case), WHEN you launch the application, the above Test2.exe.config file is loaded – hence your .net web services endpoints etc. are correctly defined.

Now, lets take the above code, and create a DLL. The simple solution is to change your project to a class:

Eg:



So we simple change the project from a console application (which creates a .exe) to a class library (which creates a .dll). No mystery here – creating a dll’s in .net is a simple change from a .exe application to a class.

Same goes for VB6, and even for c++ - the instant you create a re-use code chunk, you now creating a dll. In 99% of cases that means a simple class in .net or even VB6.

Ok, so now our project is a class. You need to modify the code a wee bit, since it not a module, but you now have this:

CODE
Public Class Test2


    Public Sub ShowSet1()

        MsgBox("Setting of setting1 = " & My.Settings.Setting1)


    End Sub


End Class


Ok, so this produces a .dll. If you tick the box “make assembly COM visible” and also check “Register for COM interop” Your DLL can NOW be used from Access!!! (ignore those huge articles on the web about building COM interfaces and all that junk – you DO NOT need ANYTHING more than the above SIMPLE code for it to consumed by Access - just check the box "make com visible" and "register com".

In Access, you can thus now use:

CODE
   Dim t2 As Object
   Set t2 = CreateObject("Test2.Test2")
  
   t2.ShowSet1


Of course we using late binding in Access. And EVEN if we early bind, you find that the properties and methods are NOT grasped by the VBA intel-sense (but WHO cares!!!).

If you set a reference to the above test2.dll from Access, then you can use this code:

CODE
  Dim t2 As New Test2.Test2
  
   t2.ShowSet1


However, early bindings gets you nothing and no intel-sense.
However, if you REALLY want an exposed interface and intei-sense to work in the VBA editor? Ok then JUST add THESE TWO SIMPLE lines to the top of your class (imports and ClassInterace)


CODE
Imports System.Runtime.InteropServices

<ClassInterface(ClassInterfaceType.AutoDual)>
Public Class Test2


    Public Sub ShowSet1()

        MsgBox("Setting of setting1 = " & My.Settings.Setting1)


    End Sub


End Class


Ok, NOW when you create the dll, and set a reference from Access you find that intel-sense in Access VBA editor does work – but you REALLY don’t need this since your likely to use late binding anyway. (this very simple approach is a HUGE contrast to the articles showing how to create a dll COM objects for Access). So there is VERY little effort required here to consume a .dll, and add the above two lines “if” you want to expose the .net interface to the VBA editor – but you REALLY don’t need to do this!


Ok now that I beat to death HOW simple it is to create a dll (COM object) in .net, your ORIGINAL problem is the .net config file (and the web services defines of endpoints) as you point out is NOT loading. The reason for this is VERY simple:

When you create dll’s in .net and THEN reference those dll in your MAIN .net .exe program, the system pulls in all of the “config” files into one main app.config that LOADS on startup.

So the .exe will auto-load the config file for you. However “dlls” NEVER load their “own” configs file. So it is generally assumed that your main .exe problem via “references” to those additional dll’s will build will create a NICE config file that pulls in all of that extra config junk into one file.

The problem of course your host program is NOT .net, and thus when you consume the above resulting .dll, in the .net folder, you see this:

CODE
Test2.dll
Test2.dll.config


So, simply add this code to “force” that .dll config file to be loaded as the MASTER overall .net config file:

CODE
    Sub New()

        Dim strP As String

        strP = System.Reflection.Assembly.GetExecutingAssembly.Location

        strP = strP & ".config"
        AppDomain.CurrentDomain.SetData("APP_CONFIG_FILE", strP)
      
    End Sub


(just add above code to our above code snip).

So the SIMPLE and COMMON act of changing your project from a .exe file to a .dll, means you created a class. However this means your loading of your config file was LOST.

It is in “general” assumed that your .dll is going to be consumed by some .net project and thus that main .exe executing will load up the main config file for you.

Since your NOW using a .dll, then of course the config file never loads and dll’s don’t load their own individual config files.

In our case the “host” program is msaccess.exe – it not a .net program and it NOT going to load the config file for you.

So your change from an .exe to a .dll is most simple (and common). And for a rather long time the idea of changing your project from a .exe to .dll simply means you now creating a class library (this even applied to VB6, but also to .net).

So you can use the above to load the app.config file into a .dll.


Regards,
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
kallal@msn.com
Go to the top of the page
 


Custom Search
RSSSearch   Top   Lo-Fi    25th April 2017 - 11:35 AM