VB.Net 2003 and VS 2005 not working together

[David L Wright II]

Does anyone know when building a msi file under VB.Net 2003, it would try to
install something from the VS 2005 Beta 1? I have both products installed.

Thanks,

 

[Jeff Johnson [MVP: VB]]

Does anyone know when building a msi file under VB.Net 2003, it would try to
install something from the VS 2005 Beta 1? I have both products

installed.

Shame on you.

Really.

NEVER install a beta on a production machine. Even if you only have one
computer to work with, you should repartition (if possible) and install a
second copy of your OS so as to have a dual-boot scenario. Then you install
the beta in your "throwaway" OS.

 

[One Handed Man \( OHM - Terry Burns \)]

You might be able to get away with it, it depends what you are intending to
install from VS2005. If your using the Framework 2.0 with 2003, then you may
get away with it in some situations but not others. I would strongly
recommend that you do not try anything for a production target in your
employers.

--

OHM ( Terry Burns )
. . . One-Handed-Man . . .

Time flies when you don't know what you're doing

 

[David L Wright II]

And If I happen to be testing out how the two products work on the same
machine?????????????

 

[Supra]

y don't u wait intil fuuly loaded intead of stupid beta version.

 

[J. Alan Rueckgauer]

You should *never* expect early betas of any product to play nicely and not
FarkleT other things on a system. You also shouldn't expect early betas to
provide any reliable measure or indication of how or if a finished product
will work "side by side" They are only intended to give us some early
exposure to the new platform's capabilities and changes.

Take it from someone who's been beta testing stuff from MS and others for
almost 30 years: things can and will go wrong, and often not give you any
indication until it is the most inopportune moment for you.

MS clearly warns against attempting to run betas on machines that are also
being used for production work. Furthermore, the first betas of VS2005 are
not licensed for go-live. You use them at your own risk and peril. If you
find interoperatiblity and compatibility issues, post bug reports where
appropriate on the website, and use the beta discussion groups to share the
gorey details. Furthermore, beta issues should not be discussed in the
released product newsgroups.

All this said, at least the uninstaller does a pretty good job of
clearing-out the beta bits and registry changes. To set things aright, use
control panel to uninstall the VS2005 products, and .Net 2.0 Framework. You
will also need to run repair on (or reinstall) your existing VS2003
installation and the 1.1 Framework. If you had SQL Server 2000 or its
client utils on your machine, you will need to reinstall that as well if you
installed SS2005.

If you must test the beta side-by-side with a production scenario, build a
separate box that is exclusively for that purpose, and that it doesn't
matter if you have to punt it.

Alan

 

[One Handed Man \( OHM - Terry Burns \)]

// U wrote
They are only intended to give us some early
exposure to the new platform's capabilities and changes
//

I disagree on this point as this is what the Alpha release is for, the beta
program is supposed to get people playing with the code to uncover as many
bugs as possible before release. Although MS do warn you about using betas
on production targets, they also know people will simply install, get into
trouble and then complain; its all part of the process.


--

OHM ( Terry Burns )
. . . One-Handed-Man . . .

Time flies when you don't know what you're doing

 

[J. Alan Rueckgauer]

I said I was referring to early betas. We've been told over and over again
at developer conferences and in various MSDN communiques that any early beta
build that is not licensed for go-live should be treated as alpha code,
regardless of what the release labeling may say. Now, were this Beta 2 or
later, or an RC, the OP's concern would certainly be warranted. However,
his posting about it on the released product ng is inappropriate. Anything
having to do with the beta should be posted in the beta community. I'm not
coming up with anything in the microsoft.private.whidbey tree from him.

Alan

 

[One Handed Man \( OHM - Terry Burns \)]

Posting to the group here Is inappropriate I agree. I've been working with
the Partner Drops for several months now and they were really flakey.
However, Beta 1 is stable enough to work with, but No I wouldnt put Beta 1
on a production machine either, however, I have built several applications
already and it's looking pretty good, the area's they seem to be lacking in
are documentation and wizards but apart from that for the most part you can
do a far bit already.

Although this is an early beta, they did say it was one of the most stable
beta releases ever and I agree so I would urge anyone who is interested to
get moving on it, as there is an awful lot to learn and its best to be ahead
of the game.



--

OHM ( Terry Burns )
. . . One-Handed-Man . . .

Time flies when you don't know what you're doing

 

[Chris Dunaway]

I disagree on this point as this is what the Alpha release is for, the beta
program is supposed to get people playing with the code to uncover as many
bugs as possible before release.

I disagree with this. The Beta is NOT meant to seek out bugs or to
determine if the product is ready to ship. It is meant to determine if the
product fills the needs of the target market. It is meant to determine if
the product meets the marketing requirements. If the intended users of the
product find that something doesn't perform as they desire or a request
feature is not present, it can be added.

Certainly, if bugs are found during this stage, they can be corrected, but
finding bugs is not the purpose of the beta. By the time a beta of a
product is released, the developers should have already removed as many
bugs as possible.

When the product reaches the Release Candidate stage, no new features can
be added and the product is only tested to make sure it is suitable for
shipping. If any bugs are found during this stage, they can be fixed or
not depending on their severity.

We generally follow the following guidelines for our products (80/20 rule):

1. The product must function as described in the user documentation and
must be consistently reliable.

2. 80% of new users will be able to use the product for the purpose it was
designed, as it is shipped, and without the need to contact customer
support

3. Users who do call for support will have their issues resolved quickly
and simply.

If it meets those guidelines, we deem it acceptable for release.
Inevitably, bugs will be found and they are fixed as quickly as possible.
But these three guidelines seem to strike a good balance.

Cheers

--
Chris

dunawayc[AT]sbcglobal_lunchmeat_[DOT]net

To send me an E-mail, remove the "[", "]", underscores ,lunchmeat, and
replace certain words in my E-Mail address.

 

[One Handed Man \( OHM - Terry Burns \)]

I would answer, but I really cant be bothered



--

OHM ( Terry Burns )
. . . One-Handed-Man . . .

Time flies when you don't know what you're doing

I disagree on this point as this is what the Alpha release is for, the beta
program is supposed to get people playing with the code to uncover as many
bugs as possible before release.

I disagree with this. The Beta is NOT meant to seek out bugs or to
determine if the product is ready to ship. It is meant to determine if the
product fills the needs of the target market. It is meant to determine if
the product meets the marketing requirements. If the intended users of the
product find that something doesn't perform as they desire or a request
feature is not present, it can be added.

Certainly, if bugs are found during this stage, they can be corrected, but
finding bugs is not the purpose of the beta. By the time a beta of a
product is released, the developers should have already removed as many
bugs as possible.

When the product reaches the Release Candidate stage, no new features can
be added and the product is only tested to make sure it is suitable for
shipping. If any bugs are found during this stage, they can be fixed or
not depending on their severity.

We generally follow the following guidelines for our products (80/20 rule):

1. The product must function as described in the user documentation and
must be consistently reliable.

2. 80% of new users will be able to use the product for the purpose it was
designed, as it is shipped, and without the need to contact customer
support

3. Users who do call for support will have their issues resolved quickly
and simply.

If it meets those guidelines, we deem it acceptable for release.
Inevitably, bugs will be found and they are fixed as quickly as possible.
But these three guidelines seem to strike a good balance.

Cheers

--
Chris

dunawayc[AT]sbcglobal_lunchmeat_[DOT]net

To send me an E-mail, remove the "[", "]", underscores ,lunchmeat, and
replace certain words in my E-Mail address.

 

[Guest]

THIS is the reason I searched for this topic in this forum. To find out if
I'd get in trouble installing 2003 & 2005 beta on the same machine. I find
out that, yes, doing so is or can be problematic. Not eveyone has extra beta
test machines or enough disk space to make multiple partitions practicable.

That makes this topic's appearance in this forum totally appropriate! It
certainly saved me from trouble and that is one of the the purposes of a
newsgroup community!

 

[Guest]

Does anyone know when building a msi file under VB.Net 2003, it would try to

install something from the VS 2005 Beta 1? I have both products installed.

David,

This is from the Readme.HTM on the disk:
To resolve this issue

Visual Studio 2005 Beta 1 provides a switch that, when turned on, forces all
applications executing on a given computer to run on the latest version of
the runtime. This switch overrides settings specified in the app.exe.config
and host.config files, which normally specify that the application run on
either version 1.0 or 1.1 of the CLR.

You can activate this switch either by setting a registry key or by setting
an environment variable:

Activate/Deactivate the Switch Using a Registry Key

Turn on the switch using the following registry setting:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\OnlyUseLatestCLR=dword:00000001
Turn off the switch using the followikng registry setting:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\OnlyUseLatestCLR=dword:00000000
Activate/Deactivate the Switch Using an Environment Variable

Activate the switch using the following variable set to "1", as follows:
COMPLUS_OnlyUseLatestCLR=1

Deactivate the switch using the following variable set to "0", as follows:
COMPLUS_OnlyUseLatestCLR=0

You can find a sample using the registry to activate/deactivate the switch
posted on GotDotNet, at the following URL:
http://www.gotdotnet.com/Community/...mpleGuid=4caff66c-df51-40ab-bd88-090d34e77520