Re: Referencing Assembly Question Without GAC?

Tech-Archive recommends: Speed Up your PC by fixing your registry

From: Mike (Mike_at_discussions.microsoft.com)
Date: 12/02/04 

Date: Wed, 1 Dec 2004 20:59:04 -0800

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??

"WizyDig" wrote:

> 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
>
>
>
>
> "Mike" <Mike@discussions.microsoft.com> wrote in message
> news:EA70D284-F051-4BD3-94D7-E53606B8A452@microsoft.com...
> > 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" wrote:
> >
> > > 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
> > >
> > > "Tampa .NET Koder" <TampaNETKoder@discussions.microsoft.com> wrote in
> > > message news:9D5A712C-8602-4D48-96D0-695441A4E574@microsoft.com...
> > > > 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
> > > >
> > > >
> > > > "Mike" wrote:
> > > >
> > > > > 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!
> > >
> > >
> > >
>
>
>

Relevant Pages

  • Re: HELP!! Im having "DLL Hell" in .NET
    ... huge known bug if you don't do this (and your dlls are larger than ... It is a client server application with 1 exe as the ... > all the supporting assemblies in directories in the root. ... > true for each reference in these assemblies. ...
    (microsoft.public.dotnet.general)
  • Re: Application security
    ... > - to prevent user from using my dlls directly, ... Assigning strong names to your assemblies is ... The ones you want to protect or the ones from which you want to ... > - I want to manage demo and customers version with license key policy. ...
    (microsoft.public.dotnet.security)
  • CCW & Managed Memory Leak?
    ... A few of these DLLs have references to .NET assemblies. ... Of course there you do have worker process recycling to help ... I'm confident that if this was running under IIS6 and using the IIS6 ...
    (microsoft.public.dotnet.framework.interop)
  • Unmanaged Multifile Assembly in C++
    ... I have several unmanaged C++ dlls that were being shared by several ... projects which were successfully converted to assemblies. ... of those dlls is dependent on another dll which we currently handle by ... (not embedding a manifest in file01 but embedding one in file02.) ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Appl. Security Problems
    ... Back up your compiled assemblies (the EXE and both DLLs) and your CAS ... the key is only used to sign the assembly at compile time. ...
    (microsoft.public.dotnet.security)