Deploying with DLLs

[=?Utf-8?B?anAybXNmdA==?=]

Using Visual Studio 2005, I have created 4 small DLLs that our company
projects can use to access common tools included in each of the separate DLL
files.

Our Visual Studio 2005 applications call the DLLs and run them without any
problem.

Now we are trying to deploy the first of these applications, and we are now
stumped. The Visual Studio 2005 Deployment Project includes all of the DLL
files and successfully creates the setup.exe file for them. The setup.exe
file will even extract all of the files (including the DLLs) on the target
machines.

Whenever we attempt to run the application, they crash as soon as we attempt
any feature which needs to access these DLLs.

One person has suggested that I need to create an app.config file for the
Windows Form Applications, but there was little about how to do this.

I researched further into editing the runtime configuration, and found that
it uses assembly binding to a particular version of the .Net Framework and
requires a Public Key token for each of these files. I have not found where I
tell this XML file what my DLL file names actually are, though.

What is involved in getting a public key token for each DLL?

If I update a DLL, do I now have to rebuild the application to accept the
updated DLL version?

Since these are Company Internal applications, all I want to do is copy a
new EXE or DLL out onto our Server whenever we have a change, and have the
users systems appear magically updated.

Is this not possible?

What am I doing wrong?

I have not done too many installs, and I get stumped whenever I step outside
of the rhelm of the Deployment Wizard.

Thanks for your help,
Joe

[Duggi]

On Jul 15, 2:12*am, jp2msft <jp2m...@discus sions.microsoft .comwrote:

Using Visual Studio 2005, I have created 4 small DLLs that our company
projects can use to access common tools included in each of the separate DLL
files.

Our Visual Studio 2005 applications call the DLLs and run them without any
problem.

Now we are trying to deploy the first of these applications, and we are now
stumped. The Visual Studio 2005 Deployment Project includes all of the DLL
files and successfully creates the setup.exe file for them. The setup.exe
file will even extract all of the files (including the DLLs) on the target
machines.

Whenever we attempt to run the application, they crash as soon as we attempt
any feature which needs to access these DLLs.

One person has suggested that I need to create an app.config file for the
Windows Form Applications, but there was little about how to do this.

I researched further into editing the runtime configuration, and found that
it uses assembly binding to a particular version of the .Net Framework and
requires a Public Key token for each of these files. I have not found where I
tell this XML file what my DLL file names actually are, though.

What is involved in getting a public key token for each DLL?

If I update a DLL, do I now have to rebuild the application to accept the
updated DLL version?

Since these are Company Internal applications, all I want to do is copy a
new EXE or DLL out onto our Server whenever we have a change, and have the
users systems appear magically updated.

Is this not possible?

What am I doing wrong?

I have not done too many installs, and I get stumped whenever I step outside
of the rhelm of the Deployment Wizard.

Thanks for your help,
Joe

For me it seems like problem with runtime on the target machine. Check
if .net runtime is installed in the target machine and also check if
any dependent dlls are missing. For this you can use tools like
dependency walker. I strongly feel its problem with target machine
environment.

-Cnu

[=?Utf-8?B?anAybXNmdA==?=]

I know the .Net Framework 2.0 is installed because the current version that
is running out on our servers was also built using VS2005 by me a few months
ago.

Our new version is going to use DLLs. Though I include them in the setup
deployment project and they do copy over to the server, the program simply
crashes with system.security .security object and wants to send the report to
Microsoft.

I can't seem to find a way to get any additional information from my app
before it crashes, though.

Someone has suggested that I specify in the app.config for the project each
DLL that I am going to include, but he wasn't able to tell me how to do it.

It is important that our applications all use the same classes, and keeping
those classes in DLLs is the easiest way of doing that. Deploying the apps
that use these DLLs onto our network is what seems to be the problem.

"Duggi" wrote:

For me it seems like problem with runtime on the target machine. Check
if .net runtime is installed in the target machine and also check if
any dependent dlls are missing. For this you can use tools like
dependency walker. I strongly feel its problem with target machine
environment.

[Duggi]

On Jul 15, 6:44*pm, jp2msft <jp2m...@discus sions.microsoft .comwrote:

I know the .Net Framework 2.0 is installed because the current version that
is running out on our servers was also built using VS2005 by me a few months
ago.

Our new version is going to use DLLs. Though I include them in the setup
deployment project and they do copy over to the server, the program simply
crashes with system.security .security object and wants to send the reportto
Microsoft.

I can't seem to find a way to get any additional information from my app
before it crashes, though.

Someone has suggested that I specify in the app.config for the project each
DLL that I am going to include, but he wasn't able to tell me how to do it.

It is important that our applications all use the same classes, and keeping
those classes in DLLs is the easiest way of doing that. Deploying the apps
that use these DLLs onto our network is what seems to be the problem.

"Duggi" wrote:

For me it seems like problem with runtime on the target machine. Check
if .net runtime is installed in the target machine and also check if
any dependent dlls are missing. For this you can use tools like
dependency walker. I strongly feel its problem with target machine
environment.- Hide quoted text -

- Show quoted text -

Hi

Lets narrow down the problem instead of assumptions.

If possible try the following

Place log statements in your new dlls. If you code does not have log
statements, you can also try putting message to the system event logs.
This help to narrow down where the issue is occuring. Once you find
out the place in code where the issue is occuring it would be easy to
troubleshoot / rectify.

Also if possible, catch exceptions at application level and log the
exception dump to a log file.

I am sure with these info you can figure out the root cause of the
defect.

-Cnu

[raylopez99]

On Jul 14, 2:12*pm, jp2msft <jp2m...@discus sions.microsoft .comwrote:

Using Visual Studio 2005, I have created 4 small DLLs that our company
projects can use to access common tools included in each of the separate DLL
files.

I have not done too many installs, and I get stumped whenever I step outside
of the rhelm of the Deployment Wizard.

Thanks for your help,
Joe

Well Joe, this sounds like heresy, but since the .DLLs are "small",
why not just combine them into the .exe executable code and distribute
the whole thing in one package? The .exe file will grow, but with
modern DVDs, lots of RAM, and fast internet access, it won't be a big
problem for most users. The others can be told to upgrade their
hardware and to buy Vista. Problem solved.

RL

[Pete Kane]

jp2msft wrote:

Using Visual Studio 2005, I have created 4 small DLLs that our company
projects can use to access common tools included in each of the separate DLL
files.

Our Visual Studio 2005 applications call the DLLs and run them without any
problem.

Now we are trying to deploy the first of these applications, and we are now
stumped. The Visual Studio 2005 Deployment Project includes all of the DLL
files and successfully creates the setup.exe file for them. The setup.exe
file will even extract all of the files (including the DLLs) on the target
machines.

Whenever we attempt to run the application, they crash as soon as we attempt
any feature which needs to access these DLLs.

One person has suggested that I need to create an app.config file for the
Windows Form Applications, but there was little about how to do this.

I researched further into editing the runtime configuration, and found that
it uses assembly binding to a particular version of the .Net Framework and
requires a Public Key token for each of these files. I have not found where I
tell this XML file what my DLL file names actually are, though.

What is involved in getting a public key token for each DLL?

If I update a DLL, do I now have to rebuild the application to accept the
updated DLL version?

Since these are Company Internal applications, all I want to do is copy a
new EXE or DLL out onto our Server whenever we have a change, and have the
users systems appear magically updated.

Is this not possible?

What am I doing wrong?

I have not done too many installs, and I get stumped whenever I step outside
of the rhelm of the Deployment Wizard.

Thanks for your help,
Joe

Hi there, it sounds as if you need to adjust the .NET Security settings
on the client look at Caspol.exe

[=?Utf-8?B?anAybXNmdA==?=]

Hello Mr. Lopez,

The one main reason for DLLs is because we have multiple apps that make the
same calls and use the same classes. I have tried placing these "common
files" in a separate folder, but whenever I try including them in one of the
solutions, Visual Studio crates a copy of it for the local folder.

Generally, our calls and classes need to be modified to display particular
data in a particular way (as commanded by the supervisors). If these calls
and classes are in multiple files, it becomes difficult to locate all the
places the code needs to be modified, then becomes questionable as to whether
all of the files received all of the changes.

Creating DLL classes has eliminated this problem.

"raylopez99 " wrote:

Well Joe, this sounds like heresy, but since the .DLLs are "small",
why not just combine them into the .exe executable code and distribute
the whole thing in one package? The .exe file will grow, but with
modern DVDs, lots of RAM, and fast internet access, it won't be a big
problem for most users. The others can be told to upgrade their
hardware and to buy Vista. Problem solved.

RL