473,320 Members | 1,930 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Referencing Assembly Question Without GAC?

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!
Nov 18 '05 #1
12 1531
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.

"Mike" <Mi**@discussions.microsoft.com> wrote in message
news:35**********************************@microsof t.com...
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!

Nov 18 '05 #2
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

"Mike" <Mi**@discussions.microsoft.com> wrote in message
news:35**********************************@microsof t.com...
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!

Nov 18 '05 #3
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!

Nov 18 '05 #4
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!

"WizyDig" wrote:
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

"Mike" <Mi**@discussions.microsoft.com> wrote in message
news:35**********************************@microsof t.com...
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!


Nov 18 '05 #5
<< You should avoid using the GAC >>

Why? Just curious.


"Kevin Spencer" <ks******@takempis.com> wrote in message
news:eL****************@tk2msftngp13.phx.gbl...
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.

"Mike" <Mi**@discussions.microsoft.com> wrote in message
news:35**********************************@microsof t.com...
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!


Nov 18 '05 #6
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" <Ta***********@discussions.microsoft.com> wrote in
message news:9D**********************************@microsof t.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!

Nov 18 '05 #7
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.

"Jim Slade" <Ji***@SladeIntl.com> wrote in message
news:ey**************@TK2MSFTNGP10.phx.gbl...
<< You should avoid using the GAC >>

Why? Just curious.


"Kevin Spencer" <ks******@takempis.com> wrote in message
news:eL****************@tk2msftngp13.phx.gbl...
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.

"Mike" <Mi**@discussions.microsoft.com> wrote in message
news:35**********************************@microsof t.com...
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!



Nov 18 '05 #8
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" <Ta***********@discussions.microsoft.com> wrote in
message news:9D**********************************@microsof t.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!


Nov 18 '05 #9
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

"Mike" <Mi**@discussions.microsoft.com> wrote in message
news:EA**********************************@microsof t.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" <Ta***********@discussions.microsoft.com> wrote in
message news:9D**********************************@microsof t.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!


Nov 18 '05 #10
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.

--
Scott
http://www.OdeToCode.com/blogs/scott/

On Wed, 1 Dec 2004 13:35:04 -0800, "Mike"
<Mi**@discussions.microsoft.com> wrote:
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" <Ta***********@discussions.microsoft.com> wrote in
message news:9D**********************************@microsof t.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!



Nov 18 '05 #11
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" <Mi**@discussions.microsoft.com> wrote in message
news:EA**********************************@microsof t.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" <Ta***********@discussions.microsoft.com> wrote in
message news:9D**********************************@microsof t.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!


Nov 18 '05 #12
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" <Mi**@discussions.microsoft.com> wrote in message
news:EA**********************************@microsof t.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" <Ta***********@discussions.microsoft.com> wrote in
message news:9D**********************************@microsof t.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!


Nov 18 '05 #13

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
by: Torrance S. | last post by:
Hi, I have a class in an assembly that references a value in web.config like this: <appSettings> <add key="mykey" value="myvalue"/> </appSettings> string temp =...
12
by: Mark Broadbent | last post by:
Hi guys, just going through remoting at the moment and a couple of questions relating to .net in general has surfaced. Firstly I have seen in the designer that for the namespace and many of its...
12
by: Pollux | last post by:
I'm having trouble doing someting apparently simple. I'm still not very familiar with Visual Studio 2003, so apologies if I've missed something obvious. Basically my problem is the following. I...
4
by: Ron | last post by:
I need to write a custom textbox control that references an object located in the Global.asax class, but I can't compile the control into a DLL without including the reference to the project DLL...
9
by: Brett Romero | last post by:
Say I have a library (A.dll) with a method that accepts a collection of a specific type. The type is defined in B.dll. In A.dll, I need to loop through this collection and reference fields of...
1
by: Tim F | last post by:
Problem: I'm receiving the error "File or assembly name XXXXX or one of its dependencies, was not found." when trying to execute code in an assmebly that has both a strong-name and has been...
0
by: DR | last post by:
I heard there is some trick to referencing statics in C# CLR stored procedure without having to mark the assembly as unsafe. Does anyone know this? This is usefull as the case of needing a little...
3
by: DR | last post by:
I heard there is some trick to referencing statics in VB.NET CLR stored procedure without having to mark the assembly as unsafe. Does anyone know this? This is usefull as the case of needing a...
2
by: Andrus | last post by:
I need compile in-memory assembly which references to other in-memory assembly. Compiling second assembly fails with error Line: 0 - Metadata file 'eed7li9m, Version=0.0.0.0, Culture=neutral,...
1
by: Tom | last post by:
My unsigned DLL works in my project that references it as long as I set Copy Local = true. Now I have signed the DLL with the sn.exe generated keys but have not yet moved the DLL into the GAC. ...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.