How to properly deploy shareable assemblies to a server

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Robert Myhill - 26 Aug 2003 15:57 GMT

I'm looking for a .NET "best practices" opinion on the following.

I have a .NET assembly (call it MyApp.dll) that I want to make generally
available to other people in my company. I will periodically be coming out
with new minor versions (bug fixes) and major versions (new features) of
MyApp.dll.

Other people in my company will be using MyApp.dll as a library, in that
there are some types in MyApp.dll that they will want to reference from
their own assemblies that they are building locally on their machines. So,
other developers will be creating assemblies that reference MyApp.dll.

Now for the questions:

Where should MyApp.dll live? How do I account for multiple versions of
MyApp.dll existing side-by-side, ready to be accessed from client
assemblies?

I would like MyApp.dll to be on a company server. But then what (if any)
.NET technologies do I need installed on the server? I could simply set up
a Windows directory structure on the server to account for different
versions of the assembly, and ask people to point their references at that
directory structure, but that seems very clunky.

I figure there has to be a well-known way of doing this...

Reply to this Message

Vince Henderson - 23 Sep 2003 22:54 GMT

The support for multiple versions of the same assembly is implemented by
the GAC. The best way to accomplish what you want is to install to the GAC
and use puiblisher policy to determine which version a particular instance
of an application uses. There is no support for managing multiple versions
outside the GAC. This is not a CLR matter but a FileSystem restriction.
The file system doesn't support the same file name in the same place. The
CLR provides no support for multiple versions in an arbitrary directory
structure. Even if you provide probing paths, probing stops at the first
match of the simple name. So first found would always be the one to be
loaded. This could be overcome with app configuration, by adding codebase
hints for each version. (See codebase and assemblybinding elements in .Net
FrameworkSDK\Reference\ConfigurationFileSchema or on MSDN ). However, then
you need to manage the deployment of the config files to the apps that need
it.

Given your desires, have you considered using a WebService to manage access
to your implementation? See .NET FrameworkSDK\QuickStarts\ASP.NET Quick
Start for examples of WebServices. A WebServvice can expose an API that
can be consumed essentially the same way your standalone assembly would.
The server would have to have the Framework installed and ASP.NET enabled.

Vince
Common Language Runtime

This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------

| From: "Robert Myhill" <rmyhill@mathsoft.com>
| Subject: How to properly deploy shareable assemblies to a server
[quoted text clipped - 36 lines]
|
| I figure there has to be a well-known way of doing this...

Vince
Common Language Runtime

This posting is provided "AS IS" with no warranties, and confers no rights.

Reply to this Message

Rate this thread:

How to properly deploy shareable assemblies to a server

Free Magazines