Please vote on this suggestion...

[Urs Eichmann]

Make (at least Class Library) Projects shareable between VS 2003 und 2005

http://lab.msdn.microsoft.com/produ...edbackid=572a25b7-4b3d-4364-8bd1-72fd99a18693

Thank you!
Urs

 

[Stephany Young]

I will not be voting for it.

In my opinion, adding a file to both projects and keeping them is sync is a
matter of someone doing their job properly, in other words, a managerial
function. I do not expect MS to add functionality to save me from myself.

If you've got people who can't manage a simple exercise like keeping 2
projects in sync then what are you going to do when someone adds some
FrameWork 2.0 specific code into a 'library' and then someone else attempts
to compile the Framework 1.1 the project?

 

[Daniel]

Me neither. I totally agree, this would be a bad idea.

 

[Herfried K. Wagner [MVP]]

I will not be voting for it.

In my opinion, adding a file to both projects and keeping them is sync is
a matter of someone doing their job properly, in other words, a managerial
function. I do not expect MS to add functionality to save me from myself.

Mhm... Maybe support for adding a project reference in VS 2005 to the
VS.NET 2003 class library that will open in a separate instance of VS.NET
2003 is the be better approach, especially for very large projects
consisting of lots of projects. I agree with Urs that migration from VS.NET
2003 to VS 2005 will be harder without some sort of integration of VS.NET
2003 projects into VS 2005.

 

[Herfried K. Wagner [MVP]]

Me neither. I totally agree, this would be a bad idea.

I don't like the idea too, but this doesn't mean that the problem doesn't
exist.

 

[Stephany Young]

I wasn't saying that I don't recognise potential problems.

What I didn't agree with was, specifically, the proposal, for the reasons I
gave.

 

[Urs Eichmann]

In my opinion, adding a file to both projects and keeping them is sync is
Of course it is a matter of doing the job properly. But believe me,
sooner or later you *will* forget to add the new file to the other
solution, because you're under pressure or have a bad day or whatever...

With the same reason you could argue that there should be no Garbage
Collector in .NET, because if everyone gets rid of the memory used by
their objects properly, there would be no need for it... but as can be
seen in reality, this is not always the case and a GC is desperately
needed. C++ people try to do it without GC... that's where all the
Memory leaks come from...

Im my opinion syncing between two Projects is a fully automatable
process - and what CAN be automated SHOULD be, otherwise there will be a
mistake creeping in sooner or later.

 

[Stephany Young]

Comparing it to the GC is just a nonsense.

The operation of the GC has absolutely nothing to do with adding a source
file to one or more projects in the IDE.

If YOU really want it then write an add-in to do it for you. Don't expect MS
to force something that you happen to want upon everybody else, especially
those who specifically don't want it.

There are lots of things that I would like to have in either the .NET
runtime or the VS.NET IDE. If I really want them then I write them myself.
Then they do exactly what I want.

 

[Urs Eichmann]

Comparing it to the GC is just a nonsense.

The operation of the GC has absolutely nothing to do with adding a source
file to one or more projects in the IDE.

I disagree. In both situations, it is an automatism which wants to
relieve the developer from error-prone work which he *clould* to
manually, but it is better if it is automated because the end product
will be less faulty.

But if you want, another situation: Why is there SCC integration in
Visual Studio? After all, you could check-in and check-out your files by
hand outside the IDE. But it would lead to much more errors (forgetting
to check-in files and so on), because people tend to forget things if
they have to do a task in multiple places.

Urs

 

[Stephany Young]

Whatever ...

I disagree. In both situations, it is an automatism which wants to relieve
the developer from error-prone work which he *clould* to manually, but it
is better if it is automated because the end product will be less faulty.

But if you want, another situation: Why is there SCC integration in Visual
Studio? After all, you could check-in and check-out your files by hand
outside the IDE. But it would lead to much more errors (forgetting to
check-in files and so on), because people tend to forget things if they
have to do a task in multiple places.

Urs

 

[Jay B. Harlow [MVP - Outlook]]

Urs,
In addition to the other comments.

Your "solution" may actually introduce more problems then it solves. One of
the major problems I see is when the 2005 developer starts using Generics in
the 2003 class library. Or the 2005 developer uses a new method or type that
2003 does not have, especially one that .NET 2.0 makes obsolete... Limiting
the 2005 developer to only what's in 2003 feels like a "waste of time".

I was going to offer creating 2 class library projects & use VSS to share
the source files, however this may have the same problems as above. I can
see 2 class libraries & two code bases, however maintenance may be an
issue...

The other thought I had was to leave the project at 2003 until there are no
more 2003 projects that reference it, then migrate it to 2005. The 2005
projects that use it would reference the assembly itself, until the class
library was migrated to 2005...

Further my understanding is that .NET 2.0 will be able to run 1.0 & 1.1
assemblies "as is", however 1.0 & 1.1 will not be able to run 2.0
assemblies, as the meta data in the assembly changed. So if anything VS.NET
2005 would need the ability to reference a VS.NET 2003 project. I can see
referencing the VS.NET 2003 project in read-only mode, I wonder how hard it
would be to create such an add-on...

NOTE: Currently I only share class libraries within a single solution, the
entire solution will be migrated, so I have not given this issue (sharing a
class library between a 2003 & 2005 solution) much thought.

Hope this helps
Jay

| Make (at least Class Library) Projects shareable between VS 2003 und 2005
|
|
http://lab.msdn.microsoft.com/produ...edbackid=572a25b7-4b3d-4364-8bd1-72fd99a18693
|
| Thank you!
| Urs

 

[Herfried K. Wagner [MVP]]

If YOU really want it then write an add-in to do it for you. Don't expect
MS to force something that you happen to want upon everybody else,
especially those who specifically don't want it.

I don't see how this feature would affect your code, and thus I don't see a
reason why it's not worth discussing it if it helps (maybe a large number
of) other users.

 

[Guest]

Jay, I have not looked at VB.Net 2005 but I was assuming that all my vb.Net
2003 code would work in 2005. I hope this is true! If I understand this
thread correctly, it is only talking about using a 2003 class library in both
2005 and 2003 after it's migrated to 2005. Is this correct?

I have lost a lot of time converting VB3 programs to VB5/6, etc. and now am
converting them to VB.Net 2003. I'm getting a little ticked off at
Microsoft. If I have to yet again convert them to VB.Net 2005, I'm going to
another programming system!

 

[Guest]

Just curious as to why this would be necessary. I had thought that when I
upgraded to VB.Net 2005 that I would delete VB.Net 2003 from my computer and
use exclusively 2005 thus avoiding this problem. Won't this work? Why would
one want to keep vb.Net 2003 after upgrading to VB.Net 2005?

 

[Jay B. Harlow [MVP - Outlook]]

Dennis,
All your 2003 code should work in 2005, however all your 2005 will not work
in 2003. If you are attempting to share source between 2003 & 2005 I would
recommend keeping it at the 2003 syntax level. This is similar to 2002 &
2003 & using the shift operators ("<<" & ">>") or using "For Each Item as
Object In collection"

The "migration" to 2005 is similar to opening a 2002 project in 2003. It
updates the .vbproj file to the new format, the code itself doesn't change.

You may have Obsolete warnings where you used a type or type member that is
now Obsolete as there is a "new & improved" type or type member to use
instead.

For details on Obsolete APIs in the various versions of .NET see:

http://www.gotdotnet.com/team/changeinfo/default.aspx

Hope this helps
Jay

| Jay, I have not looked at VB.Net 2005 but I was assuming that all my
vb.Net
| 2003 code would work in 2005. I hope this is true! If I understand this
| thread correctly, it is only talking about using a 2003 class library in
both
| 2005 and 2003 after it's migrated to 2005. Is this correct?
|
| I have lost a lot of time converting VB3 programs to VB5/6, etc. and now
am
| converting them to VB.Net 2003. I'm getting a little ticked off at
| Microsoft. If I have to yet again convert them to VB.Net 2005, I'm going
to
| another programming system!
|
| "Jay B. Harlow [MVP - Outlook]" wrote:
|
| > Urs,
| > In addition to the other comments.
| >
| > Your "solution" may actually introduce more problems then it solves. One
of
| > the major problems I see is when the 2005 developer starts using
Generics in
| > the 2003 class library. Or the 2005 developer uses a new method or type
that
| > 2003 does not have, especially one that .NET 2.0 makes obsolete...
Limiting
| > the 2005 developer to only what's in 2003 feels like a "waste of time".
| >
| > I was going to offer creating 2 class library projects & use VSS to
share
| > the source files, however this may have the same problems as above. I
can
| > see 2 class libraries & two code bases, however maintenance may be an
| > issue...
| >
| > The other thought I had was to leave the project at 2003 until there are
no
| > more 2003 projects that reference it, then migrate it to 2005. The 2005
| > projects that use it would reference the assembly itself, until the
class
| > library was migrated to 2005...
| >
| > Further my understanding is that .NET 2.0 will be able to run 1.0 & 1.1
| > assemblies "as is", however 1.0 & 1.1 will not be able to run 2.0
| > assemblies, as the meta data in the assembly changed. So if anything
VS.NET
| > 2005 would need the ability to reference a VS.NET 2003 project. I can
see
| > referencing the VS.NET 2003 project in read-only mode, I wonder how hard
it
| > would be to create such an add-on...
| >
| > NOTE: Currently I only share class libraries within a single solution,
the
| > entire solution will be migrated, so I have not given this issue
(sharing a
| > class library between a 2003 & 2005 solution) much thought.
| >
| > Hope this helps
| > Jay
| >
| > | > | Make (at least Class Library) Projects shareable between VS 2003 und
2005
| > |
| > |
| >
http://lab.msdn.microsoft.com/produ...edbackid=572a25b7-4b3d-4364-8bd1-72fd99a18693
| > |
| > | Thank you!
| > | Urs
| >
| >
| >

 

[Urs Eichmann]

Jay,

Urs,
In addition to the other comments.

Your "solution" may actually introduce more problems then it solves. One of
the major problems I see is when the 2005 developer starts using Generics in
the 2003 class library. Or the 2005 developer uses a new method or type that
2003 does not have, especially one that .NET 2.0 makes obsolete... Limiting
the 2005 developer to only what's in 2003 feels like a "waste of time".

This is of course an issue. But this can be overcome be using
conditional compiling, with #If and #End If. That means certain methods
will be for consumable for 2005 projects only - or if they have to be
consumed by 2003 projects, they'll have to be written without Using,
Generics etc.

I was going to offer creating 2 class library projects & use VSS to share
the source files, however this may have the same problems as above. I can
see 2 class libraries & two code bases, however maintenance may be an
issue...

The other thought I had was to leave the project at 2003 until there are no
more 2003 projects that reference it, then migrate it to 2005. The 2005
projects that use it would reference the assembly itself, until the class
library was migrated to 2005...

This is what we are probably going to do, if there is no help from MS.
However, this means we always have to open one VS 2003 and one 2005
instance, doing code changes in the shared libraries in the 2003
instance, reloading the solution in the 2005 instance... this will be
much of a drawback compared to today where you can have everything
within one Visual Studio instance. I don't quite understand why I seem
to be the only one having this problem around here...

Further my understanding is that .NET 2.0 will be able to run 1.0 & 1.1
assemblies "as is",

yes

however 1.0 & 1.1 will not be able to run 2.0

assemblies, as the meta data in the assembly changed.

AFAIK unless you specifically mark them as 1.1 / 1.0 compatible.

So if anything VS.NET

2005 would need the ability to reference a VS.NET 2003 project. I can see
referencing the VS.NET 2003 project in read-only mode, I wonder how hard it
would be to create such an add-on...

well if it is only read-only, you can reference the DLL instead as well,
I guess...

NOTE: Currently I only share class libraries within a single solution, the
entire solution will be migrated, so I have not given this issue (sharing a
class library between a 2003 & 2005 solution) much thought.

Lucky you! We have about 20 different solutions to maintain here, all
with the same tool libraries...

Best regards,
Urs

 

[Cor Ligthert]

Hallo,

I really don't see anything realistic in this discussion.

There are so many methods in VSNet, let the ones who want this vote for it.

We should be able to make our own decisions to use it or to tell if it would
be used in an organisation.

When that is not possible in your organisation, than it is better to do
something about that, than to make something impossible from the Big
Brother side.

The wall in Berlin is fallen now already a long time ago you know.

(For me there are more important issues so I don't vote for it. The time can
in my opinion be spent better, however that does not mean for me that others
should not who find it important).

Just my thought,

Cor

 

[Jay B. Harlow [MVP - Outlook]]

Urs,
| yes
|
| however 1.0 & 1.1 will not be able to run 2.0
| > assemblies, as the meta data in the assembly changed.
|
| AFAIK unless you specifically mark them as 1.1 / 1.0 compatible.

I'll have to find my web reference, as that was NOT the impression I got. My
understanding was if you compile an assembly with a 2.0 compiler it will
only run in 2.0 & later, as the meta data & IL opcodes have changed... Now
if only I can remember where I read that...

Of course you can compile with the 1.1 or 1.0 compiler & then you will be
fine... I understand that MS Build (the new build engine in .NET) supports
specifying which version of the compiler to use, however I'm not sure if or
how VS.NET is going to expose that ability...

Hope this helps
Jay


| Jay,
|
| > Urs,
| > In addition to the other comments.
| >
| > Your "solution" may actually introduce more problems then it solves. One
of
| > the major problems I see is when the 2005 developer starts using
Generics in
| > the 2003 class library. Or the 2005 developer uses a new method or type
that
| > 2003 does not have, especially one that .NET 2.0 makes obsolete...
Limiting
| > the 2005 developer to only what's in 2003 feels like a "waste of time".
|
| This is of course an issue. But this can be overcome be using
| conditional compiling, with #If and #End If. That means certain methods
| will be for consumable for 2005 projects only - or if they have to be
| consumed by 2003 projects, they'll have to be written without Using,
| Generics etc.
|
| >
| > I was going to offer creating 2 class library projects & use VSS to
share
| > the source files, however this may have the same problems as above. I
can
| > see 2 class libraries & two code bases, however maintenance may be an
| > issue...
| >
| > The other thought I had was to leave the project at 2003 until there are
no
| > more 2003 projects that reference it, then migrate it to 2005. The 2005
| > projects that use it would reference the assembly itself, until the
class
| > library was migrated to 2005...
|
| This is what we are probably going to do, if there is no help from MS.
| However, this means we always have to open one VS 2003 and one 2005
| instance, doing code changes in the shared libraries in the 2003
| instance, reloading the solution in the 2005 instance... this will be
| much of a drawback compared to today where you can have everything
| within one Visual Studio instance. I don't quite understand why I seem
| to be the only one having this problem around here...
|
| >
| > Further my understanding is that .NET 2.0 will be able to run 1.0 & 1.1
| > assemblies "as is",
|
| yes
|
| however 1.0 & 1.1 will not be able to run 2.0
| > assemblies, as the meta data in the assembly changed.
|
| AFAIK unless you specifically mark them as 1.1 / 1.0 compatible.
|
| So if anything VS.NET
| > 2005 would need the ability to reference a VS.NET 2003 project. I can
see
| > referencing the VS.NET 2003 project in read-only mode, I wonder how hard
it
| > would be to create such an add-on...
|
| well if it is only read-only, you can reference the DLL instead as well,
| I guess...
|
| >
| > NOTE: Currently I only share class libraries within a single solution,
the
| > entire solution will be migrated, so I have not given this issue
(sharing a
| > class library between a 2003 & 2005 solution) much thought.
|
| Lucky you! We have about 20 different solutions to maintain here, all
| with the same tool libraries...
|
| Best regards,
| Urs

 

[Guest]

Thanks Jay. I looked thru the lists on the links you gave me and none seem
to involve anything that I do so I should be able let the 2005 accept my 2003
code without any changes needed on my part.

I do hope they fixed some of the bugs in some of the 2003 controls and
hopefully extended some of their functionality. M'soft controls have always
been a bit "elementary" without many bells and whistles.

Thanks again.

Dennis,
All your 2003 code should work in 2005, however all your 2005 will not work
in 2003. If you are attempting to share source between 2003 & 2005 I would
recommend keeping it at the 2003 syntax level. This is similar to 2002 &
2003 & using the shift operators ("<<" & ">>") or using "For Each Item as
Object In collection"

The "migration" to 2005 is similar to opening a 2002 project in 2003. It
updates the .vbproj file to the new format, the code itself doesn't change.

You may have Obsolete warnings where you used a type or type member that is
now Obsolete as there is a "new & improved" type or type member to use
instead.

For details on Obsolete APIs in the various versions of .NET see:

http://www.gotdotnet.com/team/changeinfo/default.aspx

Hope this helps
Jay

| Jay, I have not looked at VB.Net 2005 but I was assuming that all my
vb.Net
| 2003 code would work in 2005. I hope this is true! If I understand this
| thread correctly, it is only talking about using a 2003 class library in
both
| 2005 and 2003 after it's migrated to 2005. Is this correct?
|
| I have lost a lot of time converting VB3 programs to VB5/6, etc. and now
am
| converting them to VB.Net 2003. I'm getting a little ticked off at
| Microsoft. If I have to yet again convert them to VB.Net 2005, I'm going
to
| another programming system!
|
| "Jay B. Harlow [MVP - Outlook]" wrote:
|
| > Urs,
| > In addition to the other comments.
| >
| > Your "solution" may actually introduce more problems then it solves. One
of
| > the major problems I see is when the 2005 developer starts using
Generics in
| > the 2003 class library. Or the 2005 developer uses a new method or type
that
| > 2003 does not have, especially one that .NET 2.0 makes obsolete...
Limiting
| > the 2005 developer to only what's in 2003 feels like a "waste of time".
| >
| > I was going to offer creating 2 class library projects & use VSS to
share
| > the source files, however this may have the same problems as above. I
can
| > see 2 class libraries & two code bases, however maintenance may be an
| > issue...
| >
| > The other thought I had was to leave the project at 2003 until there are
no
| > more 2003 projects that reference it, then migrate it to 2005. The 2005
| > projects that use it would reference the assembly itself, until the
class
| > library was migrated to 2005...
| >
| > Further my understanding is that .NET 2.0 will be able to run 1.0 & 1.1
| > assemblies "as is", however 1.0 & 1.1 will not be able to run 2.0
| > assemblies, as the meta data in the assembly changed. So if anything
VS.NET
| > 2005 would need the ability to reference a VS.NET 2003 project. I can
see
| > referencing the VS.NET 2003 project in read-only mode, I wonder how hard
it
| > would be to create such an add-on...
| >
| > NOTE: Currently I only share class libraries within a single solution,
the
| > entire solution will be migrated, so I have not given this issue
(sharing a
| > class library between a 2003 & 2005 solution) much thought.
| >
| > Hope this helps
| > Jay
| >
| > | > | Make (at least Class Library) Projects shareable between VS 2003 und
2005
| > |
| > |
| >
http://lab.msdn.microsoft.com/produ...edbackid=572a25b7-4b3d-4364-8bd1-72fd99a18693
| > |
| > | Thank you!
| > | Urs
| >
| >
| >