Sharing Code

[Jonathan Wood]

Greetings,

I'd like to write any number of classes and then use those classes from any
number of .NET applications.

Since we've supposedly left "DLL Hell" and ActiveX objects behind, what has
taken it's place.

Can anyone point me in the right direction getting started learning the best
way to write a library of routines and then being able to access those
routines from several different .NET applications?

Thanks.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Jonathan Wood wrote:

Greetings,

I'd like to write any number of classes and then use those classes from
any number of .NET applications.

Since we've supposedly left "DLL Hell" and ActiveX objects behind, what
has taken it's place.

We are still using dll files. We just left most of the hellish parts of
it behind us.

For example:

Avoiding DLL Hell: Introducing Application Metadata in the Microsoft
..NET Framework
http://msdn.microsoft.com/msdnmag/is...a/default.aspx

Can anyone point me in the right direction getting started learning the
best way to write a library of routines and then being able to access
those routines from several different .NET applications?

Create a Class Library project and put some classes in it. You can
either compile this and use the dll file produced, or add the project to
any solution.

--
Göran Andersson
_____
http://www.guffa.com

[pedrito]

It's a piece of cake. You basically create a "Class Library" project. That
will create a DLL. All your classes will be in one or more namespaces that
you create inside that DLL.

In projects that use that library, you simply add a reference to the DLL in
your project.

Let's say you have the namespace MyLib and the class MyClass in it.

You then create an application. In your application project, you'll
reference MyLib.dll

In your code, you'll do something like this:

using MyLib;

void SomeMethod()
{
MyClass myClass = new MyClass();
}

And that's all there is to it, really. Couldn't be much simpler.

You simply deploy a copy of the DLL in the same directory as your
application.

Thing can get more complex. You can start getting into signed applications
and versioning issues, but for the most part, it's pretty easy.

Pete

"Jonathan Wood" <jw***@softcircuits.comwrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...

Greetings,

I'd like to write any number of classes and then use those classes from
any number of .NET applications.

Since we've supposedly left "DLL Hell" and ActiveX objects behind, what
has taken it's place.

Can anyone point me in the right direction getting started learning the
best way to write a library of routines and then being able to access
those routines from several different .NET applications?

Thanks.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Carl Daniel [VC++ MVP]]

Jonathan Wood wrote:

Greetings,

I'd like to write any number of classes and then use those classes
from any number of .NET applications.

Since we've supposedly left "DLL Hell" and ActiveX objects behind,
what has taken it's place.

Can anyone point me in the right direction getting started learning
the best way to write a library of routines and then being able to
access those routines from several different .NET applications?

You put them in DLLs. This doesn't result in "DLL Hell" because such DLLs
are then generally deployed "app local" - in the applications 'bin'
directory, rather than in some silly place like %systemroot%.

-cd

[Jonathan Wood]

Carl,

>Can anyone point me in the right direction getting started learning
the best way to write a library of routines and then being able to
access those routines from several different .NET applications?

You put them in DLLs. This doesn't result in "DLL Hell" because such DLLs
are then generally deployed "app local" - in the applications 'bin'
directory, rather than in some silly place like %systemroot%.

That wouldn't work very well if I was using the lib from several different
applications. Either I'd need to put all the applications in the same
directory, or I'd need store multiple copies of the DLL.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Jonathan Wood]

Yep, I tried that and it worked fine. That was easy. Although, the idea of
copying shared libraries to a subfolder of each application that uses the
libraries is definitely out.

Thanks.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com
"pedrito" <pixbypedrito at yahoo.comwrote in message
news:Io******************************@giganews.com ...

It's a piece of cake. You basically create a "Class Library" project. That
will create a DLL. All your classes will be in one or more namespaces that
you create inside that DLL.

In projects that use that library, you simply add a reference to the DLL
in your project.

Let's say you have the namespace MyLib and the class MyClass in it.

You then create an application. In your application project, you'll
reference MyLib.dll

In your code, you'll do something like this:

using MyLib;

void SomeMethod()
{
MyClass myClass = new MyClass();
}

And that's all there is to it, really. Couldn't be much simpler.

You simply deploy a copy of the DLL in the same directory as your
application.

Thing can get more complex. You can start getting into signed applications
and versioning issues, but for the most part, it's pretty easy.

Pete

"Jonathan Wood" <jw***@softcircuits.comwrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...

>Greetings,

I'd like to write any number of classes and then use those classes from
any number of .NET applications.

Since we've supposedly left "DLL Hell" and ActiveX objects behind, what
has taken it's place.

Can anyone point me in the right direction getting started learning the
best way to write a library of routines and then being able to access
those routines from several different .NET applications?

Thanks.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Jon Skeet [C# MVP]]

Jonathan Wood <jw***@softcircuits.comwrote:

Yep, I tried that and it worked fine. That was easy. Although, the idea of
copying shared libraries to a subfolder of each application that uses the
libraries is definitely out.

Why? It has distinct advantages:

1) It's really obvious which version of the library you're using
2) You can replace that version very easily
3) You don't need any extra setup steps

You *can* use the GAC for all of this, but in my view that makes it
easier to fall into versioning problems again. It's all do-able in
theory, but it's easy to make mistakes.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[pedrito]

Jon (as usual), is right about this. You're going to make your life harder
if you use the GAC.

In my personal and professional experience (I work on a very large scale
commercial .NET based app), it is much easier to simply ship the proper
version with the app and keep them together in the same folder. I've never
found a reason to use the GAC.

The whole idea of "DLL hell" was based on the problem of multiple apps
wanting to use different versions of the same DLLs in the Windows/System32
folder, and using the GAC is just relocating the problem. Granted, the GAC
allows multiple versions to co-exist, but it's still more problematic than
just keeping the DLLs with the app.
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP*********************@msnews.microsoft.com. ..

Jonathan Wood <jw***@softcircuits.comwrote:

>Yep, I tried that and it worked fine. That was easy. Although, the idea
of
copying shared libraries to a subfolder of each application that uses the
libraries is definitely out.

Why? It has distinct advantages:

1) It's really obvious which version of the library you're using
2) You can replace that version very easily
3) You don't need any extra setup steps

You *can* use the GAC for all of this, but in my view that makes it
easier to fall into versioning problems again. It's all do-able in
theory, but it's easy to make mistakes.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[pedrito]

"Jonathan Wood" <jw***@softcircuits.comwrote in message
news:uu**************@TK2MSFTNGP03.phx.gbl...

Carl,

>>Can anyone point me in the right direction getting started learning
the best way to write a library of routines and then being able to
access those routines from several different .NET applications?

You put them in DLLs. This doesn't result in "DLL Hell" because such
DLLs are then generally deployed "app local" - in the applications 'bin'
directory, rather than in some silly place like %systemroot%.

That wouldn't work very well if I was using the lib from several different
applications. Either I'd need to put all the applications in the same
directory, or I'd need store multiple copies of the DLL.

Can you explain to us why this wouldn't work? Just curious. You seem pretty
convinced this is a problem, but maybe you're seeing problems where problems
don't exist. If you can tell us why that won't work, maybe we can understand
a little better what the problem is.

[Jonathan Wood]

Jon,

>Yep, I tried that and it worked fine. That was easy. Although, the idea
of
copying shared libraries to a subfolder of each application that uses the
libraries is definitely out.

Why?

At least for in-house libraries, think about what happens when you fix
something in the library. You now need to update all those copies. I guess
it's just a matter of a spending a little time copying the file as long as
you have an always-current list of every application that uses each library,
but I prefer not to have to track that kind of thing. It is definitely more
error prone and can raise issues when you find out one of the applications
isn't using the latest fixes.

1) It's really obvious which version of the library you're using

It's more obvious if every application on your computer is referencing the
same DLL.

2) You can replace that version very easily

It's easier to only replace it in one location.

3) You don't need any extra setup steps

Obviously, my take is a little different on this.

You *can* use the GAC for all of this, but in my view that makes it
easier to fall into versioning problems again. It's all do-able in
theory, but it's easy to make mistakes.

The types of versioning issues typical with so-called DLL Hell have not
really been an issue for me using my own libraries. It's definitely
something to at least consider with libraries you plan to distribute widely.

Thanks.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Jonathan Wood]

Please see my reply to Jon Skeet.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

"pedrito" <pixbypedrito at yahoo.comwrote in message
news:Qo******************************@giganews.com ...

"Jonathan Wood" <jw***@softcircuits.comwrote in message
news:uu**************@TK2MSFTNGP03.phx.gbl...

>Carl,

>>>Can anyone point me in the right direction getting started learning
the best way to write a library of routines and then being able to
access those routines from several different .NET applications?

You put them in DLLs. This doesn't result in "DLL Hell" because such
DLLs are then generally deployed "app local" - in the applications 'bin'
directory, rather than in some silly place like %systemroot%.

That wouldn't work very well if I was using the lib from several
different applications. Either I'd need to put all the applications in
the same directory, or I'd need store multiple copies of the DLL.

Can you explain to us why this wouldn't work? Just curious. You seem
pretty convinced this is a problem, but maybe you're seeing problems where
problems don't exist. If you can tell us why that won't work, maybe we can
understand a little better what the problem is.

[Jon Skeet [C# MVP]]

Jonathan Wood <jw***@softcircuits.comwrote:

Yep, I tried that and it worked fine. That was easy. Although, the idea
of
copying shared libraries to a subfolder of each application that uses the
libraries is definitely out.

Why?

At least for in-house libraries, think about what happens when you fix
something in the library. You now need to update all those copies.

Indeed. However, think about the alternative: you want to introduce a
change in one copy of the library and *only* have it affect a single
application; or you want to introduce it to different applications
gradually, as you become more confident in it. You can only do this by
either using different versions and the GAC, or using a separate copy
of the file for each application. The latter is easier.

I guess
it's just a matter of a spending a little time copying the file as long as
you have an always-current list of every application that uses each library,
but I prefer not to have to track that kind of thing. It is definitely more
error prone and can raise issues when you find out one of the applications
isn't using the latest fixes.

I prefer fine-grained control over what gets upgraded to blindly
applying a change to everything on the system.

1) It's really obvious which version of the library you're using

It's more obvious if every application on your computer is referencing the
same DLL.

Nope - you still need to find it in the GAC. If it's sitting there in
the same directory as the application, I fail to see how any
alternative is easier.

2) You can replace that version very easily

It's easier to only replace it in one location.

Yes - which is often far more desirable than the risky business of
applying it to all applications arbitrarily.

3) You don't need any extra setup steps

Obviously, my take is a little different on this.

So you think that installing something in the GAC is easier than
copying a file? If you take an application that *solely* consists of a
few files, you can do xcopy deployment. You can't do that if you need
to install stuff in the GAC.

You *can* use the GAC for all of this, but in my view that makes it
easier to fall into versioning problems again. It's all do-able in
theory, but it's easy to make mistakes.

The types of versioning issues typical with so-called DLL Hell have not
really been an issue for me using my own libraries. It's definitely
something to at least consider with libraries you plan to distribute widely.

If you choose to ignore a problem which has been so common that it's
got a nickname, that's your call of course.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jonathan Wood]

Jon,

>At least for in-house libraries, think about what happens when you fix
something in the library. You now need to update all those copies.

Indeed. However, think about the alternative: you want to introduce a
change in one copy of the library and *only* have it affect a single
application; or you want to introduce it to different applications
gradually, as you become more confident in it. You can only do this by
either using different versions and the GAC, or using a separate copy
of the file for each application. The latter is easier.

For those cases that you cite, yes. They would be very rare cases for me,
however,

>It's more obvious if every application on your computer is referencing
the
same DLL.

Nope - you still need to find it in the GAC. If it's sitting there in
the same directory as the application, I fail to see how any
alternative is easier.

I haven't yet looked into this GAC. So far, I simply followed the steps that
someone suggest of referencing the DLL. If I do that with all applications,
then updating or fixing the DLL will require exactly zero steps to ensure
all applications are upgraded to the new version. That is easier than any
scenario you've described.

I think about in-house library files I've used in the past. The biggest
issue I run into is upgrading the library and then making sure every
application uses the newest version. On the other hand, in the 20 years I've
been programming, I've yet to have any backwards compatibility issues when
any library I've ever released. I understand the issues concerning DLL
conflicts. But for me, particularly for in-house stuff, only one of these
issues is a concern.

If you choose to ignore a problem which has been so common that it's
got a nickname, that's your call of course.

If you get defensive, you may choose to put down my position by suggesting
I'm simply ignoring the problem. I've acknowledged the position you've taken
but fail to see how that really matters with in-house applications in the
very rare (in my case, never) instances where they would arise. From my
perspective, what I'm doing is addressing the very problems that my
experience had taught me I'm likely to run into.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Jonathan Wood]

Smithers,

<< I'll probably just add references to the DLL >>

How does that satisfy any of your complaints about distributing multiple
copies of the .dll with each application?

What I've been describing is referencing the *same* DLL from several
applications, which are running only on my desktop BTW.

What distribution are you referring to?

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[J.B. Moreno]

In article <Os**************@TK2MSFTNGP06.phx.gbl>,
Jonathan Wood <jw***@softcircuits.comwrote:

As I indicated elsewhere, I can see wanting to stick the library in the same
folder as the application for libraries that receive wide distribution. But,
for in-house stuff, I don't like that approach.

When deciding to how to use/distribute a library, you need to look at
your situation and determine what your needs are.

Decide the things you want to happen, and how important they are...what
trade off as are you willing to make, what aren't you willing to do
without....

And there will be your answer as to what to do....

--
J.B. Moreno

[Smithers]

RE:
<< What I've been describing is referencing the *same* DLL from several
applications >>

Yes, I know - same DLL from several applicaitons - got it several posts ago.

So - what do you mean by "referencing the same DLL from several
applications" Are you talking about "setting a reference" to the DLL in
Visual Studio? If not, then how specifically are you planning to "set a
reference" outside of Visual Studio. It's starting to sound like you are
planning on running your applications from within Visual Studio - is that
correct.

RE:
<< What distribution are you referring to?>>

Your applications, of course.

-S

"Jonathan Wood" <jw***@softcircuits.comwrote in message
news:uV**************@TK2MSFTNGP04.phx.gbl...

Smithers,

><< I'll probably just add references to the DLL >>

How does that satisfy any of your complaints about distributing multiple
copies of the .dll with each application?

What I've been describing is referencing the *same* DLL from several
applications, which are running only on my desktop BTW.

What distribution are you referring to?

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Jonathan Wood]

Smithers,

<< What I've been describing is referencing the *same* DLL from several
applications >>

Yes, I know - same DLL from several applicaitons - got it several posts
ago.

If I add a reference to the DLL from my applications running on my desktop,
then there is no need to make multiple copies of the DLL. I can just have
multiple applications reference the same DLL.

So - what do you mean by "referencing the same DLL from several
applications" Are you talking about "setting a reference" to the DLL in
Visual Studio? If not, then how specifically are you planning to "set a
reference" outside of Visual Studio. It's starting to sound like you are
planning on running your applications from within Visual Studio - is that
correct.

So it sounds like you are saying when I build an application in Visual
Studio that has references to a DLL, that the compiled application will not
run outside Visual Studio. Is that what you're saying?

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Carl Daniel [VC++ MVP]]

Jonathan Wood wrote:

Smithers,

><< What I've been describing is referencing the *same* DLL from
several applications >>

Yes, I know - same DLL from several applicaitons - got it several
posts ago.

If I add a reference to the DLL from my applications running on my
desktop, then there is no need to make multiple copies of the DLL. I
can just have multiple applications reference the same DLL.

>So - what do you mean by "referencing the same DLL from several
applications" Are you talking about "setting a reference" to the DLL
in Visual Studio? If not, then how specifically are you planning to
"set a reference" outside of Visual Studio. It's starting to sound
like you are planning on running your applications from within
Visual Studio - is that correct.

So it sounds like you are saying when I build an application in Visual
Studio that has references to a DLL, that the compiled application
will not run outside Visual Studio. Is that what you're saying?

It might not. Adding a reference to a DLL at a specific location doesn't
make that DLL available on the load path for your program . For your
program to function outside the IDE, you either need to provide a copy of
the DLL in your application folder (which is what VS does by default), or
set the appropriate module loading path via your application's configu file
to enable the CLR to find your DLL.

The reference that's embedded in the compiled code doesn't have a full path
to the DLL - it has the assembly name, version number and strong-name
information corresponding to the DLL that you specified at compile time.
None of that tells the CLR how to find the DLL at run time, however.

-cd

[Carl Daniel [VC++ MVP]]

GlennDoten wrote:

Jon Skeet [C# MVP] wrote:

>Do you obfuscate your code, btw?

No, never.

>I seem to remember (and it would make
sense) that it makes that slightly more tricky too.

I don't see how. Signing an assembly (I think better said: giving a
strong name to an assembly) just adds a little block of metadata to
the assembly. Any obfuscator would still work the same way with an
assembly that is strong-named.

If you obfuscate your code, then you have to re-sign after obfuscation.
Obfuscation tools have options to do this. The same is true for intrusive
profiling - the profiler has to re-sign the module after injecting the
profiling stubs.

All of this gets to be compilcated in larger organizations where the SNK
file is controlled by a distribution group and is not available to the
developers. In this case, devs must delay-sign their modules, or do all
testing with unsigned modules (which can't be in the GAC) then test again
with signed modules (which can be in the GAC), etc. None of the steps are
difficult - it's just more steps.

-cd

[GlennDoten]

Carl Daniel [VC++ MVP] wrote:

GlennDoten wrote:

>Jon Skeet [C# MVP] wrote:

>>Do you obfuscate your code, btw?

No, never.

>>I seem to remember (and it would make
sense) that it makes that slightly more tricky too.

I don't see how. Signing an assembly (I think better said: giving a
strong name to an assembly) just adds a little block of metadata to
the assembly. Any obfuscator would still work the same way with an
assembly that is strong-named.

If you obfuscate your code, then you have to re-sign after obfuscation.
Obfuscation tools have options to do this. The same is true for intrusive
profiling - the profiler has to re-sign the module after injecting the
profiling stubs.

Thanks, I didn't think of that, but it makes complete sense. Since the
obfuscator is changing the bits in the assembly the hash (strong-name)
will then be different.

One more reason not to use an obfuscator!

All of this gets to be compilcated in larger organizations where the SNK
file is controlled by a distribution group and is not available to the
developers. In this case, devs must delay-sign their modules, or do all
testing with unsigned modules (which can't be in the GAC) then test again
with signed modules (which can be in the GAC), etc. None of the steps are
difficult - it's just more steps.

I believe that is why MS added support for .pfx files (instead of having
to use a .snk file).

Also, if protecting the private part of the key-pair is important,
there's no reason a .pfx couldn't be created for developers to use
during development and testing to allow full signing to be done in one
step. Then only the buildmaster would have to switch the .pfx files when
a final, release build is done. So in this case there's no additional
burden on the developers in comparison to not signing the assemblies.
And it's a solution that would probably have to be used anyhow if the
assembly must be signed.

--
-glenn-

[Jonathan Wood]

Carl,

>So it sounds like you are saying when I build an application in Visual
Studio that has references to a DLL, that the compiled application
will not run outside Visual Studio. Is that what you're saying?

It might not. Adding a reference to a DLL at a specific location doesn't
make that DLL available on the load path for your program . For your
program to function outside the IDE, you either need to provide a copy of
the DLL in your application folder (which is what VS does by default), or
set the appropriate module loading path via your application's configu
file to enable the CLR to find your DLL.

The reference that's embedded in the compiled code doesn't have a full
path to the DLL - it has the assembly name, version number and strong-name
information corresponding to the DLL that you specified at compile time.
None of that tells the CLR how to find the DLL at run time, however.

Well, I'll have to play with it a bit then. All I need right now is for
these apps to run locally. I may just check out the config setting you
mentioned.

Thanks.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Smithers]

<snip>

So it sounds like you are saying when I build an application in Visual
Studio that has references to a DLL, that the compiled application will
not run outside Visual Studio. Is that what you're saying?

Yes, that's what I'm saying.

When you set a reference to a dll in Visual Studio, it will, by default,
copy the dll (the thing you say you do NOT want to happen) to your
application's \bin directory. To check me on this, go ahead and set your
reference in Visual Studio, then right-click the referenced assembly in the
solution explorer and view properties. You will see Boolean property named
"Copy Local". When the value is "true" then Visual Studio copies the dll to
the application's \bin folder. You can proceed to develop - but when you go
to run the application outside of Visual Studio (i.e., when you have
distributed it to a user or to some location other than the VS project's
folder structure) you STILL must decide how you are going deploy the
referenced DLL. Your options have already been enumerated elsewhere in this
thread; the option that VS is assuming is that you will have one copy of the
DLL per application... thus the copy in the \bin directory. You could
alternatively place the DLL in the GAC, or in an arbitrary location provided
that you then update the codebase or probing elements in your app's .config
file.

This might help:
http://msdn2.microsoft.com/en-us/library/yx7xezcf.aspx

You still haven't answered the question:
<< what do you mean by "referencing the same DLL from several applications"
Are you talking about "setting a reference" to the DLL in Visual Studio? >>

If you were to tell us what *you believe that means*, then we might be able
to help you more efficiently. Right now we have to guess - and I'm guessing
that you have some faulty assumptions about how the CLR locates an assembly
at runtime - either from within Visual Studio or once deployed (run outside
of Visual Studio).

Setting a reference in Visual Studio, just so you know, does NOTHING to
ensure that multiple applications can use a *single copy* of a DLL, as
Visual Studio makes multiple copies (one per application) for you (per the
Copy Local = true default). Even if you set Copy Local = false, then you
still have to tell your applications how to locate the DLL once you deploy
the application and run it beyond Visual Studio (options including the GAC
or specifying location via codebase and probing elements in .config file).

HTH

-S

-S

[Smithers]

<snip>

RE:
<< All I need right now is for these apps to run locally >>

This fact is irrellevant to the CLR. It must find the referenced .DLL, and
you must control how that happens. You can't [do nothing | not make a
choice] about this... If you do not specify your preference, then Visual
Studio will decide for you. By default, Visual Studio simply copies
referenced DLL files to EACH application's \bin folder... which is what you
say you do NOT want.

-S

[Jonathan Wood]

I said I'd look into that config setting you mentioned. I understood you
were saying that would addres the issue you're talking about.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

"Smithers" <[e-mail] in message
news:eE**************@TK2MSFTNGP06.phx.gbl...

<snip>

RE:
<< All I need right now is for these apps to run locally >>

This fact is irrellevant to the CLR. It must find the referenced .DLL, and
you must control how that happens. You can't [do nothing | not make a
choice] about this... If you do not specify your preference, then Visual
Studio will decide for you. By default, Visual Studio simply copies
referenced DLL files to EACH application's \bin folder... which is what
you say you do NOT want.

-S

[Jonathan Wood]

Smithers,

When you set a reference to a dll in Visual Studio, it will, by default,
copy the dll (the thing you say you do NOT want to happen) to your
application's \bin directory.

Okay, I didn't realize it copied it. (This is the first time anything like
that was mentioned in this thread.)

You can proceed to develop - but when you go to run the application
outside of Visual Studio (i.e., when you have distributed it to a user or
to some location other than the VS project's folder structure) you STILL
must decide how you are going deploy the referenced DLL. Your options have
already been enumerated elsewhere in this thread; the option that VS is
assuming is that you will have one copy of the DLL per application... thus
the copy in the \bin directory. You could alternatively place the DLL in
the GAC, or in an arbitrary location provided that you then update the
codebase or probing elements in your app's .config file.

For my immediate needs, there really is no deployment. But, for obvious
reasons, I would like the application to be able to run outside of Visual
Studio.

Setting a reference in Visual Studio, just so you know, does NOTHING to
ensure that multiple applications can use a *single copy* of a DLL, as
Visual Studio makes multiple copies (one per application) for you (per the
Copy Local = true default). Even if you set Copy Local = false, then you
still have to tell your applications how to locate the DLL once you deploy
the application and run it beyond Visual Studio (options including the GAC
or specifying location via codebase and probing elements in .config file).

Got it.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Smithers]

I think you're on your way now... but to be sure:

RE:
<< For my immediate needs, there really is no deployment. ... >>

There is no such thing as "no deployment". I suspect you are going with a
working definition of "deployment" as at least installing your app on a
machine other than your dev box. That's not a complete understanding of
"deployment" - and at least that's not a useful definition that is congruent
with the docs that describe deployment options (XCopy, etc).

You have two basic options for running your apps on your local machine
without using the Visual Studio IDE.

1. Make use of the directory structure that Visual Studio sets up for you.
In this case, you would launch your .exe from a fulder under the \bin
directory (e.g. MyProject\bin\Debug. The debug folder is where VS places
projects you build in debug mode. You will see that all referenced
assemblies with Copy Local = true are also copied to the \bin\Debug folder
(I'm using VS2008 beta 2, but IIRC these folder structures haven't changed
from 2005).

2. Make use of some directory OTHER than that set up by Visual studio. When
you do this, you have "deployed" your application. It doesn't matter if it's
on the local machine or out to 5000 users. The easiest way to do this is to
simply copy all of the files in the \bin\Debug (or Release) folders to your
other folder. This is known as "XCopy deployment" because you are just
copying files to a new destination. If you want to make use of the GAC or
specify arbitrary folder from which to share dlls amongst apps, then you
cannot go with XCopy deployment and would have to then figure out how to get
your DLLs into the GAC or specify location via codebase or probing elements
in each application's .config file.

Note that option 1 above is really "XCopy deployment" that is done for you
by Visual Studio.

-HTH


"Jonathan Wood" <jw***@softcircuits.comwrote in message
news:ex**************@TK2MSFTNGP02.phx.gbl...

Smithers,

>When you set a reference to a dll in Visual Studio, it will, by default,
copy the dll (the thing you say you do NOT want to happen) to your
application's \bin directory.

Okay, I didn't realize it copied it. (This is the first time anything like
that was mentioned in this thread.)

>You can proceed to develop - but when you go to run the application
outside of Visual Studio (i.e., when you have distributed it to a user or
to some location other than the VS project's folder structure) you STILL
must decide how you are going deploy the referenced DLL. Your options
have already been enumerated elsewhere in this thread; the option that VS
is assuming is that you will have one copy of the DLL per application...
thus the copy in the \bin directory. You could alternatively place the
DLL in the GAC, or in an arbitrary location provided that you then update
the codebase or probing elements in your app's .config file.

For my immediate needs, there really is no deployment. But, for obvious
reasons, I would like the application to be able to run outside of Visual
Studio.

>Setting a reference in Visual Studio, just so you know, does NOTHING to
ensure that multiple applications can use a *single copy* of a DLL, as
Visual Studio makes multiple copies (one per application) for you (per
the Copy Local = true default). Even if you set Copy Local = false, then
you still have to tell your applications how to locate the DLL once you
deploy the application and run it beyond Visual Studio (options including
the GAC or specifying location via codebase and probing elements in
.config file).

Got it.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Jonathan Wood]

Smithers,

There is no such thing as "no deployment". I suspect you are going with a
working definition of "deployment" as at least installing your app on a
machine other than your dev box. That's not a complete understanding of
"deployment" - and at least that's not a useful definition that is
congruent with the docs that describe deployment options (XCopy, etc).

Well, my definition of "no deployment" for this discussion was to build my
application and then use that application file without changing its location
whatsoever. So, yeah, I guess it's hard for me to describe that as a
deployment.

You have two basic options for running your apps on your local machine
without using the Visual Studio IDE.

1. Make use of the directory structure that Visual Studio sets up for you.
In this case, you would launch your .exe from a fulder under the \bin
directory (e.g. MyProject\bin\Debug. The debug folder is where VS places
projects you build in debug mode. You will see that all referenced
assemblies with Copy Local = true are also copied to the \bin\Debug folder
(I'm using VS2008 beta 2, but IIRC these folder structures haven't changed
from 2005).

2. Make use of some directory OTHER than that set up by Visual studio.
When you do this, you have "deployed" your application. It doesn't matter
if it's on the local machine or out to 5000 users. The easiest way to do
this is to simply copy all of the files in the \bin\Debug (or Release)
folders to your other folder. This is known as "XCopy deployment" because
you are just copying files to a new destination. If you want to make use
of the GAC or specify arbitrary folder from which to share dlls amongst
apps, then you cannot go with XCopy deployment and would have to then
figure out how to get your DLLs into the GAC or specify location via
codebase or probing elements in each application's .config file.

Yeah, I'm not new to VS, only .NET, so I understand about the output folders
and I'm familiar with "XCOPY deployment."

I had understood your comments to mean I could use method 1 above with Copy
Local = false, and that there was was config setting that I could use to
tell my application how to locate a referenced assembly.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Jon Skeet [C# MVP]]

Jon Skeet [C# MVP] <sk***@pobox.comwrote:

(I wouldn't call
signing assemblies "viral"; pretty odd outlook, IMO.)

It's viral in the same way that the GPL is often considered viral - by
applying the property to one thing, it's required for others: if I want
to sign one assembly, I have to sign everything it references *and* any
unit test assemblies which want to reference its internals.

Looking back on the thread, I suspect that bringing the GPL into this
may have been a cause for confusion. The direction of "infection" of
signing is indeed in a different direction than that of the GPL - with
the GPL, it's any software that *uses* the GPL code that is "infected"
with it, whereas with signing it's the other way round.

Hopefully my previous reply will have cleared up exactly what I meant
anyway, but I just wanted to apologise if this was the source of the
confusion.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too