 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / VB.NET / October 2004VB.Net 2003 and VS 2005 not working together
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, > 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. 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.  SignatureOHM ( Terry Burns ) . . . One-Handed-Man . . . Time flies when you don't know what you're doing > 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, And If I happen to be testing out how the two products work on the same machine????????????? > 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, 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 > And If I happen to be testing out how the two products work on the same > machine????????????? [quoted text clipped - 5 lines] > > > > Thanks, // 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. SignatureOHM ( Terry Burns ) . . . One-Handed-Man . . . Time flies when you don't know what you're doing > 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 [quoted text clipped - 38 lines] > > > > > > Thanks, 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 > // U wrote > They are only intended to give us some early [quoted text clipped - 6 lines] > on production targets, they also know people will simply install, get into > trouble and then complain; its all part of the process. 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. SignatureOHM ( Terry Burns ) . . . One-Handed-Man . . . Time flies when you don't know what you're doing > 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 [quoted text clipped - 18 lines] > > on production targets, they also know people will simply install, get into > > trouble and then complain; its all part of the process. 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! "One Handed Man ( OHM - Terry Burns )" wrote: > 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. [quoted text clipped - 42 lines] > into > > > trouble and then complain; its all part of the process. On Mon, 2 Aug 2004 07:46:02 +0100, One Handed Man ( OHM - Terry Burns ) wrote: > 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 SignatureChris 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. I would answer, but I really cant be bothered SignatureOHM ( Terry Burns ) . . . One-Handed-Man . . . Time flies when you don't know what you're doing > On Mon, 2 Aug 2004 07:46:02 +0100, One Handed Man ( OHM - Terry Burns ) > wrote: [quoted text clipped - 37 lines] > > Cheers y don't u wait intil fuuly loaded intead of stupid beta version. >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, 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/UserSamples/Details.aspx?SampleGuid=4caff66c- df51-40ab-bd88-090d34e77520 Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.