Referencing Assembly Question Without GAC?

[Guest]

I found this question before I asked mine:

----<previous question>----
We are clearly going about this the wrong way so before we get too far I
would like some advice.

We have all common assemblies like our page base class etc located on our
Dev server.

We reference them in all our applications with Copy Local set to trued

We then publish them to the production server for example so each asp.net
app has a copy of the common assembly in the bin directory.

This is of course leaving us with the problem of having to replace the
assembly in every bin directory when a change is made.

What is the best practice to avoid this issue?

Thanks a million,

Jason MacKenzie"
----</previous question>----

I have this same issue, however I can't use the GAC because of different
reasons out of my control. Can someone help with the best practice?

THANKS!

 

[Kevin Spencer]

I'm not sure what "this issue" is supposed to be. You should avoid using the
GAC, and the best practice is to put your assemblies in the /bin folder. I
don't know why Jason seemed to think that every assembly needs to be
replaced when a change is made. Assuming that the change is in one project,
only that one DLL needs to be swapped out. And swappping it out is as simple
as overwriting the original DLL with the new one. What is the problem with
this?

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Neither a follower
nor a lender be.

 

[WizyDig]

If you can not use the GAC then you will have to run them locally. i.e. in
the bin directory. The GAC is there for a single point to have a dll
registered globally and have the ability to have multiple versions running
at the same time. COM type dlls can be registered with regasm.exe /codebase.
This will make them global but they need to be strong named inorder to have
multiversion capabilities.
Hope this helps
-wiz

 

[Guest]

I stand to be corrected; but I believe you can just deploy all of your common
assemblies in a bin folder located under wwwroot:
-wwwroot
----/bin

this way all sub applications can share this very same assembly deployed in
this folder. So, you would just have to replace the single assemble deployed
under the wwwroot/bin folder. try this out

 

[Guest]

The issue is that we are going to have hundreds of web sites using our
content management "framework". This framework has many assemblies that
control rendering of pages... It's similar to sharepoint. The company that I
work for has a very long promotion process with much documentation and having
to replace the one or more dll in every website for each release is not at
all possible. I need a way to use these dlls in a central cache.. "Like the
GAC".. but not the GAC.

I've looked into using reflection/appdomain but don't know if this is the
answer.
THANKS!

 

[Jim Slade]

<< You should avoid using the GAC >>

Why? Just curious.

 

[WizyDig]

When you do this you will not have the multi version version cabablities for
that you need a strong name and to register them in the GAC.

-wiz

 

[Kevin Spencer]

The GAC works a lot like the COM System Registry. It is difficult to update
DLLs loaded into the GAC, and if the version is the same, requires a reboot.
If the version isn't the same, code that uses the DLL has to be modified to
use the new version. For this reason, DLLs that require frequent updates
should be loaded into the /bin folder, where they can be easily replaced
when updated.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Neither a follower
nor a lender be.

 

[Guest]

I don't care about the version capabilities and the wwwroot/bin will not work
"for me" because I can't put things in that directory. Because of my
environment I only have control of web sites... so the best solution would be
if I could have all web sites use 1 certain web sites bin as the assembly
cache.

 

[WizyDig]

I've never attemped this but you should be about to put your DLLs any where.
If you register them with your app from a central location and then don't
create a local copy. If you look at the registered assemblies in your
project and right click on one and select properites you will see this
information.

Basically the default location is in the /bin directory. You can place the
assemblies anywhere. If you are on a hosted web farm you may run into some
permissions problems with this approach. I would contact the web host and
see if they have some work around for this.

-wiz

 

[Scott Allen]

You could use assemblyBinding in the .config file to specify a
different subdirectory for assemlies ...

<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="subdir/bin" />
</assemblyBinding>
</runtime>

... but that doesn't sound like it fits your scenario.

There is Assembly.LoadFile also.

Just remember the shadow copy feature only works from the bin
directory by default. Outside of the bin the assemblies are locked.

My suggestion would be to practice good configuration management and
deploy / update the sites as a single tested application and including
all dependant assemblies. Pushing out a single dll and copying it
across various directories sounds dangerous to me. Copying it to a
single directory sounds even more dangerous.

 

[WizyDig]

If you make changes to you common dlls you will need to recompile your
dependant dlls too if the interface changes. So why not just deploy them
when you update your individual apps. Is band width an issue with the upload
or something? We have apps that share dlls and we just push them when we
push everything else in the bin directory. Each bin directory has a copy of
the dll so when you push those dlls you push the copies too. That's the
beauty of X copy deployment. Are these COM compliant assemblies or true
..NET assemblies?

- wiz

 

[Guest]

The problem with pushing them is that in my environment I just can't deploy
100's of web sites because I changed one line of code in one dll. For each
web site promotion it takes almost a full day of work to cut throught the red
tape.

I was thinking that assemply.loadfrom and reflection might be the answer.
Maybe loading a commonshared assembly and cast to a commonshared interface.
All the references for the loaded file would also be loaded. I am confused
however about loading this file into a new appdomain to unload the files??