.NET dll config file

  • Thread starter Thread starter Suresh Gladstone
  • Start date Start date
S

Suresh Gladstone

Hi,
This is a bit with versioning and installation of
the .NET dlls. I want to perform the following, [THIS IS
WITH REFERENCE TO WINDOWS APPLICATION]
1. A third party application will be invoking my .NET dll
through COM interop . For this I have used Regasm and
registered the assembly in the registry with CODEBASE
option.

eg: regasm myDll.dll
/tlb:myDll.tlb /codebase

2.The main dll which is invoked from the third party
application has some other .NET dll references.
These .NET references are common dlls used by many other
similar main dlls. The situation is we had placed this
common dlls in the GAC and it worked fine through
reference.Now we have a business decision to move these
common dll's to a local directory in the users machine
and refer it from there. I have written a Configuration
file and set the <codeBase ...> to point to the
directory. But it is not working. Can anyone send me a
sample config file how it should be. The point of concern
here is , the configuration file should be created for
the Dll and not the Exe.

3. Process Eg:
i. I have a third party application say A ,
ii. I have a set of main assemblies say B,C,D each of
which will be independently invoked by the third party
application A
iii. I have a set of common .NET dll libraries say X,Y,Z
these will be used by the main assemblies B,C and D
Process
The application A will invoke main assembly B (which is
registered in the registry with codebase option) . I have
placed assembly B in a directory say "c:\MainDlls"
The assembly B references X,Y,Z . I want to place these
X,Y,Z dlls in a common directory (not in GAC)
say "C:\CommonDlls" . The other main assemblies C and D
will also use these common libraries from the same
directory.


|---------X
A --------------->B|---------Y
(Third party |---------Z
application)

I have the following question
1.How should be the config file written in this case.Its
for a .NET dll (not .NET exe)
2.Where should the config file be placed. Since its a
third party invokingapplication, not sure where to place
the config file.

Any help will be really appreciated.

Regards,
Suresh Gladstone
 
Suresh said:
2.The main dll which is invoked from the third party
application has some other .NET dll references.
These .NET references are common dlls used by many other
similar main dlls. The situation is we had placed this
common dlls in the GAC and it worked fine through
reference.Now we have a business decision to move these
common dll's to a local directory in the users machine
Click to expand...

hmmm, what business decision would that be? When you move the library
assemblies to a separate folder you create problems because you have to tell
the .NET assembly loader technology (Fusion) explicitly where to find the
libraries. Furthermore, your life will get much more difficult when you
decide to update the libraries and provide other versions. The best solution
is to keep the GAC because it is designed to solve all of these issues.

If you are concerned with deployment then you would be far better to
investigate the facilities that VS.NET offer you for deployment projects.
and refer it from there. I have written a Configuration
file and set the <codeBase ...> to point to the
directory. But it is not working. Can anyone send me a
sample config file how it should be. The point of concern
here is , the configuration file should be created for
the Dll and not the Exe.
Click to expand...

The first thing to note is that configuration files are for *processes* not
for libraries. So if your library is called by a "third party application"
that application's configuration file must have the entries to redirect the
codebase. You cannot create a config file just for your DLL.

This is one of many issues you'll have when you decide to eshew the
facilities of the GAC!

Note that if the library assembly is *not* signed (it does not have a strong
name) then it can only live in the application's folder, or in a folder
underneath the application's folder. If you want it to live somewhere else
then you have to sign it and give it a version.

If you use the third party application's configuration file then you will
have to post the relevant sections of that file because there is no other
way that we can help you.
3. Process Eg:
i. I have a third party application say A ,
ii. I have a set of main assemblies say B,C,D each of
which will be independently invoked by the third party
application A
Click to expand...

A.exe calls B, C D by COM? So B, C, D are .NET libraries? If so, the config
file is A.exe.config because this is the process.
iii. I have a set of common .NET dll libraries say X,Y,Z
these will be used by the main assemblies B,C and D
Process
The application A will invoke main assembly B (which is
registered in the registry with codebase option) . I have
placed assembly B in a directory say "c:\MainDlls"
The assembly B references X,Y,Z . I want to place these
X,Y,Z dlls in a common directory (not in GAC)
say "C:\CommonDlls" . The other main assemblies C and D
will also use these common libraries from the same
directory.
Click to expand...

well, the GAC is a good place to put them, but if you insist...

All of the assemblies must be signed and versioned.

A.exe.config needs to have a <dependentAssembly> for each assembly it calls
directly *and* for each assembly that they will call that is not in the
application folder nor in the GAC. Each of these must have a <codebase> for
the specific version of the assembly to point to the folder where the
assembly will be found.

You can put this in the machine.config file, but then it will apply to all
applications.

Sounds complicated? That's why the GAC is such a good idea.
I have the following question
1.How should be the config file written in this case.Its
for a .NET dll (not .NET exe)
Click to expand...

config files are only for processes, not libraries
2.Where should the config file be placed. Since its a
third party invokingapplication, not sure where to place
the config file.
Click to expand...

It should be in the same folder as the process (A.exe), unless you put these
values in machine.config. However, you really should not tamper with
machine.config. If you screw up this file, you screw it up for all .NET
applications!
Any help will be really appreciated.
Click to expand...

My advice is to rethink the decision about using the GAC. It is there
precisely for the reason that you want to use shared folders. If the
'business decision' is because your boss says so, then tell him/her to
contact me and I will put him/her right about it <g>.

Richard
 
(admitting the risk of overkill):
if B,C and D used dynamic loading to load X,Y or Z, wouldn't that do the
trick?
As Richard pointed out, .config files are for EXEs, not DLLs.
 
Let me guess.... your developing for ArcGIS.

Atleast thats what I am doing, and have spent countless hours coming up with
a suitable deployment scenario.

As of now this is what I came up with.

The Application A, uses my dlls, via a COM dll. So the entry point to my
dlls, is via a central DLL that has been registered for COM interop. (call it
B.dll)

B.dll resides in AppFolder
The DLLs that B.dll depends upon are all deployed to the AppFolder.

Now to make it all cleaner this is what you can do.
The DLLs that you wish to reference can be given a new name that would
support deploying them into subFolders.
C.dll is called Common.C.Dll and put into AppFolder\Common
d.dll is called CSharp.C.Dll and put into AppFolder\CSharp
.... you get the idea.

Now when A.exe starts up, it finds B.dll (as it was registered for COM
interop).
B.Dll will load Common.C.Dll from the common subfolder
and will load CSharp.C.Dll from the CSharp folder. This works, because that
is how the framework looks for dependent dlls

Hope it helps.
 
Back
Top