Interesting file managment feature of VS2005

[Kevin Frevert]

In the process of learning VS2005/C# (having a background in Borland Delphi
2 through 2005) I came across an interesting feature of Visual Studio's file
management. At first, it appeared there wasn't a way for me to 'share'
common business objects (ex. \Projects\Objects\Customer\CustomerObject.cs)
across multiple solutions.
When I select Add -> Existing Item, navigate to the directory, and select
the .CS file and select Add, VS *copies* the file to the solution's
directory (no longer follows the local directory structure or structure
configured in source control).
What happens when, not if, I change the file? Is this a bug? Have I just
become lazy because Delphi's default behavior to adding objects/units is to
*use* the file from where ever you added it from? How can I guarantee that
all our other developers compile the same base source code?

Then a developer on a Borland newsgroup pointed out the Add button in the
'Add Existing Item' dialog box is also a drop-down (yes, very intuitive)
that allows me to 'Add as Link'. Tada, now my business objects are shared,
and not copied.

I brought up my dilemma with 3 Microsoft Visual Studio 'experts' at PDC-2005
who basically told me sharing files in multiple projects wasn't possible
(one actually questioned why anyone would do that).

So my question, why would 'linking' not be the default behavior? Wouldn't
copying lead to more bugs (especially in a multiple developer environment)
and more file management/versioning headaches? Is there a way to make
'linking' the default 'Add' behavior?

Thanks,
Kevin

[Nicholas Paldino [.NET/C# MVP]]

Kevin,

I think that the general idea is that you would want something
side-by-side, which is why they don't just link to the files. It's just the
mindset of the app. Of course, as you have found out, the option is
available to you.

However, you have to remember that if add the same file across your
projects, then those types in that file compiled into each project will not
be the same types in the compiled assembly, and can not be interchanged or
used amongst those assemblies. If this is ok for your project, then that's
fine, but you need to be aware of it.

The thinking behind the questions as to why you would want to do that is
because the typical way to do this would be to have one project where this
file resides, and then reference that assembly from the other projects you
want to use those types in. It is seen as much easier to manage in the face
of changes (which probably leads to the thinking in VS.NET that you would
copy the file to your local project folder).

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

P.S. If you asked me, I would have been able to tell you about the "Add as
Link" option =)

"Kevin Frevert" <ke***@workdrinkingdietcoke.com> wrote in message
news:u3**************@TK2MSFTNGP10.phx.gbl...

In the process of learning VS2005/C# (having a background in Borland
Delphi 2 through 2005) I came across an interesting feature of Visual
Studio's file management. At first, it appeared there wasn't a way for me
to 'share' common business objects (ex.
\Projects\Objects\Customer\CustomerObject.cs) across multiple solutions.
When I select Add -> Existing Item, navigate to the directory, and select
the .CS file and select Add, VS *copies* the file to the solution's
directory (no longer follows the local directory structure or structure
configured in source control).
What happens when, not if, I change the file? Is this a bug? Have I just
become lazy because Delphi's default behavior to adding objects/units is
to *use* the file from where ever you added it from? How can I guarantee
that all our other developers compile the same base source code?

Then a developer on a Borland newsgroup pointed out the Add button in the
'Add Existing Item' dialog box is also a drop-down (yes, very intuitive)
that allows me to 'Add as Link'. Tada, now my business objects are
shared, and not copied.

I brought up my dilemma with 3 Microsoft Visual Studio 'experts' at
PDC-2005 who basically told me sharing files in multiple projects wasn't
possible (one actually questioned why anyone would do that).

So my question, why would 'linking' not be the default behavior? Wouldn't
copying lead to more bugs (especially in a multiple developer environment)
and more file management/versioning headaches? Is there a way to make
'linking' the default 'Add' behavior?

Thanks,
Kevin

[Bruce Wood]

The typical way to share code across projects is to put the shared code
into a DLL and reference that DLL from several projects.

Compiling the same source code into multiple projects, particularly if
they're DLLs, leads to problems, as Nicholas pointed out.

[Kevin Frevert]

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:Og**************@TK2MSFTNGP12.phx.gbl...

Kevin,

I think that the general idea is that you would want something
side-by-side, which is why they don't just link to the files. It's just
the mindset of the app. Of course, as you have found out, the option is
available to you.

Perhaps initially, but in my experience managing thousands of files,
multiple developers (and Dilbert-ish management :), less copying and more
using solves all kinds of problems. Working with Delphi over the years, it
seems VS is taking me ten steps backwards.
However, you have to remember that if add the same file across your
projects, then those types in that file compiled into each project will
not be the same types in the compiled assembly, and can not be
interchanged or used amongst those assemblies. If this is ok for your
project, then that's fine, but you need to be aware of it.
I'm not exactly sure what you are saying. What exactly cannot be
interchanged? If I have a CustomerObject.cs file and a type of Retail,
Dealer, etc, a DLL or EXE would build against one file, not two. If I have
to change a type, all I have to remember is to change one file, re-compile
any/all assemblies/applications that use that file, and I'm done. In VS it
seems the default behavior is copy the file from somewhere (assuming the
developer fetched the correct file from version control) compile and hope
for the best.
The thinking behind the questions as to why you would want to do that
is because the typical way to do this would be to have one project where
this file resides, and then reference that assembly from the other
projects you want to use those types in. It is seen as much easier to
manage in the face of changes (which probably leads to the thinking in
VS.NET that you would copy the file to your local project folder).

Yes, ideally I would want to build an assembly with all the common
libraries/objects and when something changes, I change the assembly and my
apps reflect that change with no changes to app's source code. What scares
me is after using VB4, DLL hell will soon become Assembly hell. As nice as
they were, the VS folks at PDC didn't give me a nice future to look forward
to :)
Hope this helps.

Yes, Thank you.

krf

[Bruce Wood]

Kevin Frevert wrote:

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in

However, you have to remember that if add the same file across your
projects, then those types in that file compiled into each project will
not be the same types in the compiled assembly, and can not be
interchanged or used amongst those assemblies. If this is ok for your
project, then that's fine, but you need to be aware of it.

I'm not exactly sure what you are saying. What exactly cannot be
interchanged? If I have a CustomerObject.cs file and a type of Retail,
Dealer, etc, a DLL or EXE would build against one file, not two. If I have
to change a type, all I have to remember is to change one file, re-compile
any/all assemblies/applications that use that file, and I'm done.

Yes, but you missed Nicholas's point. The point is that the name of a
type, like Dealer, in .NET is not just "Dealer". It's the name of the
assembly in which it resides, followed by the namespace in which it's
declared, followed by the type name. So, if you compile "Dealer" into
multiple assemblies (DLLs), then the types will be incompatible.

The CLR doesn't care what source file the type came from. All it cares
about is the assembly from which it was loaded, and the namespace and
typename (which in your case would be the same, since it's always
compiled from the same source file). So, if you compile Dealer into a
DLL and compile it into another assembly, the two Dealers will be
incompatible within the CLR.

The thinking behind the questions as to why you would want to do that
is because the typical way to do this would be to have one project where
this file resides, and then reference that assembly from the other
projects you want to use those types in. It is seen as much easier to
manage in the face of changes (which probably leads to the thinking in
VS.NET that you would copy the file to your local project folder).

Yes, ideally I would want to build an assembly with all the common
libraries/objects and when something changes, I change the assembly and my
apps reflect that change with no changes to app's source code. What scares
me is after using VB4, DLL hell will soon become Assembly hell. As nice as
they were, the VS folks at PDC didn't give me a nice future to look forward
to :)

In theory, there should never be an Assembly hell, because there are
only two ways you can deploy DLLs:

1. As private assemblies that live in the same directory as the
executable. So long as every executable has its own directory, you can
release them independently without having DLL version problems.

2. As assemblies installed in the GAC, which supports multiple versions
of the same assembly, and loads the version that the EXE asks for.

I haven't gotten into using the GAC because I work in a small shop with
simple requirements. However, Microsoft has gone to a lot of work to
built a framework that understands versioning and was designed from the
ground up to eliminate DLL Hell. Whether it will make good on that
promise remains to be seen, but it's certainly a huge step forward, and
I think that it removes any objections to using DLLs in the first place.

[Kevin Frevert]

"Bruce Wood" <br*******@canada.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...

Yes, but you missed Nicholas's point. The point is that the name of a
type, like Dealer, in .NET is not just "Dealer". It's the name of the
assembly in which it resides, followed by the namespace in which it's
declared, followed by the type name. So, if you compile "Dealer" into
multiple assemblies (DLLs), then the types will be incompatible.

Yes, I missed the point. So if AssemblyA and AssemblyB are using the same
underlying class (either the same file or copied), you cannot compare/use
types declared in the .CS file in AssemblyC (and AssemblyC has reference to
A & B)? If so, that's a situation I'll try to avoid.

In theory, there should never be an Assembly hell, because there are
only two ways you can deploy DLLs:

1. As private assemblies that live in the same directory as the
executable. So long as every executable has its own directory, you can
release them independently without having DLL version problems.

2. As assemblies installed in the GAC, which supports multiple versions
of the same assembly, and loads the version that the EXE asks for.

IMO, that is pretty close to hell :) I think I'd rather have a bad venereal
disease than managing assemblies/GACs on several hundred PCs (who has what
version installed where?) Too many bad COM dll experiences I guess.

What is the best way to manage common assemblies? How do you decide what is
GAC'ed or what is copied into the application's directory? What keeps a
lazy network admin from copying the assembly in multiple places trying to
solve an end-user problem (one of my bad COM experiences)? Is there a
'best' way?

krf

[Bruce Wood]

If you're dealing on that large a scale, I would hunker down with a
book on .NET versioning and figure out how it works. As I said, we
don't use it here, because we're a tiny shop and can control everything
pretty easily, so I'm no expert on how it's designed to work.

The folks in Redmond put a lot of thought into this to solve precisely
the kinds of versioning problems that used to cause DLL Hell. While
their solution may not be ideal, I doubt that it's junk. It's worth
looking into, at the very least.