Deploying with Custom References

[jp2msft]

Using VS2005:

We have created custom class projects that output to DLL files.

In our App, we add these to the list of Solution References and include them
in the code.

When the App compiles, it places copies of the DLL files in the output
(bin's Debug/Release folders).

Now we are trying to test the deployment. We created an Installer project
and listed each of the DLL files with the Exclude property set to False.

We install the application, and there are no errors.

When we launch the application, it appears to be crashing about where it is
supposed to be accessing one of the DLL files.

Is there something special that needs to be done to install DLL files along
with a project?

I tried manually registering them using the Run command and "regsvr32", but
none of the DLLs have entry points, and nothing was registered.

 

[jp2msft]

Ok, I'm not sitting idly by waiting for a response. I'm trying to get this
fixed.

That being said, here is some more information:

In the Installer, I had originally placed all of the DLLs in the same folder
as the executable, but the Application Folder's DefaultLocation was directed
to a folder on our network. The install worked, but the application crashed.

Take 2: Thinking this is what I want to eventually do, I moved the DLL files
into a custom subfolder of the Common Files Folder. This time, my program
would not even start! Wow! Very bad.

Take 3: I changed the Application Folder's DefaultLocation to "C:\TEMP" and
placed all of the DLLs in this same folder. Eureka! Now the program runs fine.

So, is there a way to deply an application and give it an install location
on the network? My next step in debugging is to try this using one of the
network's drive letters.

If someone is knowledgeable about these things, please inform me what I'm
doing incorrectly.

Thanks.

 

[Phill W.]

jp2msft wrote:

When loading Assemblies (Dll's), the Framework uses its own set of rules
about where to look and the DefaultLocation folder is one of those places.

In the Installer, I had originally placed all of the DLLs in the same folder
as the executable, but the Application Folder's DefaultLocation was directed
to a folder on our network. The install worked, but the application crashed.

.... because in trying to load the Dll, it looked in the DefaultLocation
and the Assembly wasn't there.

Take 2: Thinking this is what I want to eventually do, I moved the DLL files
into a custom subfolder of the Common Files Folder. This time, my program
would not even start! Wow! Very bad.
Agreed.

Take 3: I changed the Application Folder's DefaultLocation to "C:\TEMP" and
placed all of the DLLs in this same folder. Eureka! Now the program runs fine.

.... so the Normal search sequence that the Framework uses found the Dll.

You need to add a .exe.config (app.config in the project, copied when
you rebuild it) that specifies where the executable should look for its
dependent assemblies which, IIRC, is based on the /installed/ location
of the executable, not the DefaultLocation.

[program*.exe.config*]
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity
name="---assembly---name---"
publicKeyToken="---"
culture="neutral"
/>
<codeBase
version="1.0.0.0"
href=".\*library.dll*" />
</dependentAssembly>
</assemblyBinding>
</runtime>

So, is there a way to deply an application and give it an install location
on the network? My next step in debugging is to try this using one of the
network's drive letters.

Be warned: The Framework does not distinguish between your [user's]
'Q'-drive, say, and www.DodgyAndDangerousSoftware.com. To run /any/
..Net code from a network fileshare, you must establish Code Access
Security Policies to allow this. Your program /might/ work without this
but any code /not/ installed on a local disk is treated as suspect and
run in a security "sandbox" with far lower permissions than you might
expect.

Regsvr32 is for registering COM dll's, not .Net assemblies; they are
/totally/ different things and need different tools to "register" them.

HTH,
Phill W.

 

[jp2msft]

Thanks Phil.

I think that gave me enough information to go find out how to solve my
problems.

Regards,
Joe

jp2msft wrote:

When loading Assemblies (Dll's), the Framework uses its own set of rules
about where to look and the DefaultLocation folder is one of those places.

In the Installer, I had originally placed all of the DLLs in the same folder
as the executable, but the Application Folder's DefaultLocation was directed
to a folder on our network. The install worked, but the application crashed.

.... because in trying to load the Dll, it looked in the DefaultLocation
and the Assembly wasn't there.

Take 2: Thinking this is what I want to eventually do, I moved the DLL files
into a custom subfolder of the Common Files Folder. This time, my program
would not even start! Wow! Very bad.
Agreed.

Take 3: I changed the Application Folder's DefaultLocation to "C:\TEMP" and
placed all of the DLLs in this same folder. Eureka! Now the program runs fine.

.... so the Normal search sequence that the Framework uses found the Dll.

You need to add a .exe.config (app.config in the project, copied when
you rebuild it) that specifies where the executable should look for its
dependent assemblies which, IIRC, is based on the /installed/ location
of the executable, not the DefaultLocation.

[program*.exe.config*]
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity
name="---assembly---name---"
publicKeyToken="---"
culture="neutral"
/>
<codeBase
version="1.0.0.0"
href=".\*library.dll*" />
</dependentAssembly>
</assemblyBinding>
</runtime>

So, is there a way to deply an application and give it an install location
on the network? My next step in debugging is to try this using one of the
network's drive letters.

Be warned: The Framework does not distinguish between your [user's]
'Q'-drive, say, and www.DodgyAndDangerousSoftware.com. To run /any/
..Net code from a network fileshare, you must establish Code Access
Security Policies to allow this. Your program /might/ work without this
but any code /not/ installed on a local disk is treated as suspect and
run in a security "sandbox" with far lower permissions than you might
expect.

Regsvr32 is for registering COM dll's, not .Net assemblies; they are
/totally/ different things and need different tools to "register" them.

HTH,
Phill W.

 

[jp2msft]

Wait!

Phil, a quick question:

Where is a good spot to look for this? I don't exectly know what it is
called, and googling for "App.config" produced thousands of "how to" for
websites.

Your version of VS must be a little different from mine, because I did not
have the particular xmlns schema you used above. My VS2005 Pro had the
following urn:schemas-microsoft-com: datatypes, rowset, xml-data, xml-msdata,
xml-msdatasource, and xslt.

What is a good name for what I am trying to do? I'd even go so far as to
accept a web link to a tutorial if you know of one!

jp2msft wrote:

When loading Assemblies (Dll's), the Framework uses its own set of rules
about where to look and the DefaultLocation folder is one of those places.

In the Installer, I had originally placed all of the DLLs in the same folder
as the executable, but the Application Folder's DefaultLocation was directed
to a folder on our network. The install worked, but the application crashed.

.... because in trying to load the Dll, it looked in the DefaultLocation
and the Assembly wasn't there.

Take 2: Thinking this is what I want to eventually do, I moved the DLL files
into a custom subfolder of the Common Files Folder. This time, my program
would not even start! Wow! Very bad.
Agreed.

Take 3: I changed the Application Folder's DefaultLocation to "C:\TEMP" and
placed all of the DLLs in this same folder. Eureka! Now the program runs fine.

.... so the Normal search sequence that the Framework uses found the Dll.

You need to add a .exe.config (app.config in the project, copied when
you rebuild it) that specifies where the executable should look for its
dependent assemblies which, IIRC, is based on the /installed/ location
of the executable, not the DefaultLocation.

[program*.exe.config*]
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity
name="---assembly---name---"
publicKeyToken="---"
culture="neutral"
/>
<codeBase
version="1.0.0.0"
href=".\*library.dll*" />
</dependentAssembly>
</assemblyBinding>
</runtime>

So, is there a way to deply an application and give it an install location
on the network? My next step in debugging is to try this using one of the
network's drive letters.

Be warned: The Framework does not distinguish between your [user's]
'Q'-drive, say, and www.DodgyAndDangerousSoftware.com. To run /any/
..Net code from a network fileshare, you must establish Code Access
Security Policies to allow this. Your program /might/ work without this
but any code /not/ installed on a local disk is treated as suspect and
run in a security "sandbox" with far lower permissions than you might
expect.

Regsvr32 is for registering COM dll's, not .Net assemblies; they are
/totally/ different things and need different tools to "register" them.

HTH,
Phill W.

 

[Phill W.]

Where is a good spot to look for this? I don't exectly know what it is
called, and googling for "App.config" produced thousands of "how to" for
websites.

Yep; pretty much every .Net web site has an app.config in it whose use
is completely and utterly different from what we're trying to achieve
here. :-}

I'm afraid I can't recall /where/ I found this originally (probably the
same rummaging around that you're doing at the moment) and finding it
really relies on knowing the right "magic words" - try "codeBase" and
"dependentAssembly" and you should get [a bit] close[r].

Your version of VS must be a little different from mine

.... yes; my example was taken from VS'2003 ...

What is a good name for what I am trying to do?

It seems to go under the banner of "sharing or reusing Assemblies that
/can't/ go in the GAC (Global Assembly Cache)"

I'd even go so far as to accept a web link to a tutorial if you know
of one!

Not a tutorial as such, but at least a definitive list of the elements
you've got to play with ...

http://msdn.microsoft.com/en-us/library/0kk0kk35(VS.80).aspx

Well; as definitive as we're ever likely to get. ;-)

HTH,
Phill W.