Sharing Code

[Smithers]

Re: Sharing Code

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 "referencin g 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" <jwood@softcirc uits.comwrote in message
news:uVMSSKr4HH A.5740@TK2MSFTN GP04.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]

Re: Sharing Code

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 "referencin g 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]]

Re: Sharing Code

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 "referencin g 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]]

Re: Sharing Code

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]

Re: Sharing Code

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]

Re: Sharing Code

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]

Re: Sharing Code

<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 "referencin g 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]

Re: Sharing Code

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

Re: Sharing Code

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" <A@B.comwrote in message
news:eEoXID04HH A.1484@TK2MSFTN GP06.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]

Re: Sharing Code

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]

Re: Sharing Code

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\D ebug. 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" <jwood@softcirc uits.comwrote in message
news:exkbH704HH A.2108@TK2MSFTN GP02.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]

Re: Sharing Code

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\D ebug. 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]]

Re: Sharing Code

Jon Skeet [C# MVP] <skeet@pobox.co mwrote:

(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 - <skeet@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too