Deployment problems

[Scanner2001]

This may not be the best group to post to, so if there are any
suggestions as to a different group, please let me know.

Here is what we are doing, we have a couple of dlls that are shared
(i.e. used by a number of other dlls and applications). These dlls have
their own setup process, built with VS2003 setup and deployment package.
They are strongly named and have keys. We specify to deploy to the GAC only
on the target production server.

The problem comes when app1.exe want to use shared1.dll. On the
development machine, the shared1.dll is deployed to the GAC and to the
Microsoft.NET\Framework\v1.1.4322 folder so that it can be referenced from
the add reference dialog in the VS IDE. When the setup and deployment
package is built for the app1.exe, it includes the shared1.dll. I do not
want to do this, I think. The problem this poses is that any application
that uses the shared dll will have to deploy its own copy of the
shared1.dll. This seems like application isolation to the extreme. On the
other hand, I do not want to deploy the shared dlls to single folder,
because this is no different than the c:\winnt\system32 dll folder, also
causing problems.

What I thought I could do is deploy the shared1.dll on its own to the
target machine, then let .Net pick this up from the GAC.

So, 2 issues.
1 is how to remove the shared dll dependency from the app1.exe deployment
package, possibly working like the launch condition for the .Net framework.
2 is how to force each application to use the most recent/appropriate shared
dll on the target server, as specified from the GAC deployment of the shared
dll.

Thanks,
J

[Dan Bass]

Jeff,

You can exclude the DLL from the setup project... in the dependencies
section, right click and say "Exclude".

Do this only if you're SURE the dependency will exist on the target server.
If this is an assumption, then the exe will automatically reference the GAC
loaded assembly.

Thanks.

Dan.

"Scanner2001" <je************@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

This may not be the best group to post to, so if there are any
suggestions as to a different group, please let me know.

Here is what we are doing, we have a couple of dlls that are shared
(i.e. used by a number of other dlls and applications). These dlls have
their own setup process, built with VS2003 setup and deployment package.
They are strongly named and have keys. We specify to deploy to the GAC
only
on the target production server.

The problem comes when app1.exe want to use shared1.dll. On the
development machine, the shared1.dll is deployed to the GAC and to the
Microsoft.NET\Framework\v1.1.4322 folder so that it can be referenced from
the add reference dialog in the VS IDE. When the setup and deployment
package is built for the app1.exe, it includes the shared1.dll. I do not
want to do this, I think. The problem this poses is that any application
that uses the shared dll will have to deploy its own copy of the
shared1.dll. This seems like application isolation to the extreme. On the
other hand, I do not want to deploy the shared dlls to single folder,
because this is no different than the c:\winnt\system32 dll folder, also
causing problems.

What I thought I could do is deploy the shared1.dll on its own to the
target machine, then let .Net pick this up from the GAC.

So, 2 issues.
1 is how to remove the shared dll dependency from the app1.exe deployment
package, possibly working like the launch condition for the .Net
framework.
2 is how to force each application to use the most recent/appropriate
shared
dll on the target server, as specified from the GAC deployment of the
shared
dll.

Thanks,
J

[Bonj]

Deploy the DLL with the application, whether it's already installed on the
server or not. Tell the installer to put it in the GAC, and if the *same
version* is already in the GAC, it'll only keep one copy. (If you have
auto-increment version numbers on and you compiled it at a different time,
then that will constitute it being a different version.)
However if you reference compiled binaries and deploy app1, that includes
dll1, and then you deploy app2 that includes dll1, if dll1 hasn't been
changed between installations there will still be the copy of dll1 from when
app1 installed in the GAC, and app2 will use it from the GAC happily.
"Scanner2001" wrote:

This may not be the best group to post to, so if there are any
suggestions as to a different group, please let me know.

Here is what we are doing, we have a couple of dlls that are shared
(i.e. used by a number of other dlls and applications). These dlls have
their own setup process, built with VS2003 setup and deployment package.
They are strongly named and have keys. We specify to deploy to the GAC only
on the target production server.

The problem comes when app1.exe want to use shared1.dll. On the
development machine, the shared1.dll is deployed to the GAC and to the
Microsoft.NET\Framework\v1.1.4322 folder so that it can be referenced from
the add reference dialog in the VS IDE. When the setup and deployment
package is built for the app1.exe, it includes the shared1.dll. I do not
want to do this, I think. The problem this poses is that any application
that uses the shared dll will have to deploy its own copy of the
shared1.dll. This seems like application isolation to the extreme. On the
other hand, I do not want to deploy the shared dlls to single folder,
because this is no different than the c:\winnt\system32 dll folder, also
causing problems.

What I thought I could do is deploy the shared1.dll on its own to the
target machine, then let .Net pick this up from the GAC.

So, 2 issues.
1 is how to remove the shared dll dependency from the app1.exe deployment
package, possibly working like the launch condition for the .Net framework.
2 is how to force each application to use the most recent/appropriate shared
dll on the target server, as specified from the GAC deployment of the shared
dll.

Thanks,
J