Oh My God , Not again ! Whidbey Delay

it seems that Yukon and Whidbey are shifted again(!!!!) up till first half 2005.
I guess it's good to have a heavily tested product but come on it became endless.
so what do you think guys.
check it out at :
http://www.eweek.com/article2/0,1759,1546150,00.asp
ByeI'm happy that the product will be well tested and "rock-solid" when it ships.

I am sad, because I was holding off on some redesign of a couple of webpages because I really wanted Master Pages and a few other things.

Well, it will keep me employed, as I will rewrite the pages once Whidbey comes out so I can take advantage of all of the cool stuff in it.

Richard
Even if they come out at the same time, it's going to take more time to migrate db's over from 2000 to Yukon. That's a big ticket item to sell, as companies tend to be very serious and cautious about moving DB's around -- as well they should be.

And Whidbey is already pretty solid.

The real issue here is that a lot people think it's silly to tie Whidbey to Yukon, myself included.

The point here is that so much is rolled up into Whidbey that has absolutely nothing to do with Yukon, that it's absurd to wait until Yukon is finished.
That'll be no good for me because my MSDN subscription ends early next year (assuming the next VS.net would be available to MSDN subscribers). What's the use of having a subscription if you don't get any real software updates? I'll be bummed if it comes out a short time after my subscription ends :(

Then again I expected this to happen so I wouldn't be suprised if it gets pushed back to the summer or fall of 2005. MS products always seem to come out 1 year after they were supposed to come out...
I am implementing some features in Widbey myself. :-)
I am already seriously tempted to use Whidbey for any internal projects. I run a small consulting company and it makes for a nice "proving ground." I am considering building my company website with it. :)

However, releasing anything Whidbey related to a client would be out of the question. It's a shame about the delay. There's so many great things in ASP.NET 2.0.
Ok guys,
how about this, why don't they split the launch for the two products I mean that they said that the delay was because of the CLR integration into Yukon and some issues related to that.So, since Whidbey is still on the same old schedule "last quarter of 2004",and the delay is from the Yukon side,release the Whidbey and make another launch event for Yukon ,
but I guess they are waiting to launch the products in one day which seems to be very reasonable from commercial point of view,
see, they will save the cost of the launch event :) .
The current Alpha ASP.NET an Whidbey are already worth the progress. My feeling is that it is already more stable than Visual Studio 2002 ever was.

Why not release Whidbey, and do SP1 together with Yukon?

Well I gues this discussion has (and might still be) gone on inside Microsoft. Stick to the old schedule for Whidbey!

Old DLL keeps comming back over and over again

I have a solution with about 6 projects (1 web project, 5 control libraries). The code is all source controlled (SVN) and the product is in an ongoing development state.

I am using a 3rd party component which recently upgraded their control from version 5.4.2 to 6.0.0, so naturally I wanted to upgrade the code I have. I open the solution in VS2005 deleted the reference to version 5.4.2 and created a new reference to version 6.0.0 and compiled. I look in the bin and 5.4.2 was just reinstated... from where? and why??

I went into C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\<project name> and cleared everything out, then repeated the steps from above and, low and behold, the 5.4.2 dll just keeps coming back.

I'm at pure frustration at this point. I never ran into situations like this in VS2003... any help would be greatly appreciated!!!!

Hi,

Make sure that version 5.4.2 dll is deleted from all folders in your web project and also delete the VSWebCache folder in Documents & Settings. Also, open your project file in NotePad and check for any references for the old dll. Remove the same if you see any such entry.

Let me know if this works.

Vivek

Hi Vivek,

All 5.4.2 dll's have been deleted, there is no project file for web applications in .NET 2.0 and I can't find the VSWebCache folder in Documents & Settings. Can you give me an exact path?

thanks.

>...there is no project file for web applications in .NET 2.0

Actually your post did not specify if you are using Web Application Project option or not (generally I avoid using the default Website model unless necessary).

In VS 2005, VSWebCache folder is not present under Documents and Settings, I gave you this option as I missed the fact that you are using VS 2005.

Coming back to your problem, if all 5.4.2 dll's have been deleted from your web project, then try to create another test project and see if the same problem occurs. Since in Website model, all files in the project folder are a part of the website, this problem should not have occured. Also try searching for old dll in your entire machine, if found, change its name for the time being.

Let me know if it works.

Vivek

It's all good ;)

I don't know why this was happenning but I found out that it was occuring only in compile time. So I simply removed the reference, added the 6.0.0 dll's manually, and simply opened the web project with my browser and it was good after that.

Strange stuff but I have learned to expect these types of unexplained behaviours from microsoft ;)

thanks again!

I just upgraded the control to version 6.0.2 and I'm going through the same problem AGAIN. I would like to know what is the path the *VS2005* goes through to pick up the dll's, meaning where does it look first, second, third and last before it pulls in old dll's. Can anyone address this issue?

I guess, visual studio .net always looks at the assembly in the bin folder, when it compiles.. Or if you referenced another project, instead of an assembly, then it would get the assembly from its object/debug folder of the referenced project..

Any here is how the runtime locates assemblies during runtime

How the Runtime Locates Assemblies

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconhowruntimelocatesassemblies.asp

Is there an equivalent article on msdn2 for .net 2.0?

noamw:

Is there an equivalent article on msdn2 for .net 2.0?

What makes you think the above article doesnt apply for .net 2.0

Good question. I guess my question is more specific and was not aimed at manually loading assemblies. That's why I was hopping to get more info from msdn2...
Anyway, let me try to throw this question out again and hopefully you can help me out.

I have a solution with 6 projects (1 web, 5 library's) and I have a third party component that is referenced both on the web project and in one of the libraries. I recently upgraded to a new version of this component. I did what I have been doing for years now: removed the existing reference, created a new reference to the new version's dll and compiled my solution. The old version kept creeping back into my bin after I compiled. So I took the next step: Cleared all the cache settings, deleted the folder from the Microsoft.Net/Framework/...etc folder (I was under the impression the dll's were cached there) deleted the old version from my bin and re-referenced the new dll in the project. Compiled... the old version somehow found it's way back to my bin.

I would like to know where VS2005 is pulling this dll over and over and over again...

does this make more/any sense now?

You said you are referencing this component in your web project as well as in another library project.. Did you remove the old reference in both the places.. ALso, go to bin/debug or obj/debug folders in both the projects and remove any old dll component and try again

Yes, sorry I forgot to mention this, I did upgrade the dll in both places. Funny thing is that the libraries reference actually held on to the new version. The bin/debug and obj/debug folders were cleared as well. I even ran a "clean solution" just in case and I still get that dll popping back in... it's driving me crazy.

thanks.

Is it possible for you to send us some trimmed down zipped non-working version of your project via email?

-Vivek

As much as it sucks... I can't. sorry :(
I'm having hte same issue. I had to re-chekcout the whole project just to get hte project to relinquish it's grips ont he old dll.? There has to be a reason for this.

Here are some things I've tried and know is a problem.

1) It's not in the GAC, so I don't know where the dll is being cached.

2) We have physically removed the dll from the project and built it. On building, it actually pulls the old version of hte DLL again

3) When we copy and paste the latest version of the DLL, it would actually overwrite the new dll with the old dll.

This is using a webservice, so there is no project file nor could we find where the referneces are that would cause this issue.? I have had this issue a few times now and would love any input people have on this.?