blog community

Welcome to blog community Sign in | Join | Help
in Search

Marcel de Vries, MVP Team System

.NET Technologies, Architecture and Web Development

File references refresh bug got Fixed by ASP.NET team post Beta 2!

As you might have noticed the ASP.NET team created a new project structure without solution and project files in Visual studio 2005. We found (along with plenty other customers) that the new model breaks the way we would make applications. The problem we found is that when breaking up your applications in multiple solutions (which is a very wise decision if you want to keep productive with large applications) then you would have many “file” references to other solutions within your web project. Up until beta 2 the web projects did only a once off copy of the DLL. This implicated that rebuilding a solution would never be reflected again in de web project. Obviously this would break many people’s current applications, and we felt this was a really bad way of working.

My colleague Raimond filed a bug on this and we got the feedback that this would be postponed to be fixed after Whidbey ships.(see original feedbackcenter bug form) You can imagine the disappointment at our side.

Now for the great news…..

Last week we attended the devlab on team system and we also took the opportunity to have a chat with some of the ASP.NET developers. During our meeting we also brought this issue up again and guess what…. They fixed it!

They have created a Post B2 solution for this issue. They will now add .refresh files to the bin directory and they will contain information about the location where the reference originated. When a build is done, the refresh files will be used to update the dll’s in the bin folder when needed. As you can see, providing feedback really helps and they are listening to what we have to say.

Many thanks to the ASP.NET team for listening and fixing this issue. I am sure many developers in the future will be very thankful.

Published Thursday, August 11, 2005 6:49 AM by marcelv

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

Phil Short said:

So you are repsonsible for those vermin are you?

Frankly, I hate them. We have developer in different locations working on different workstations on a multitude of projects. Not large solutions with lots of component projects like yours, no, lots of different small to medium projects. We use third party tools with lots of DLL's, and the particular toolsets have quarterly releases. They're better than they were, but still often there are backward compatability issues.

Our problem arises when we get a change request on a project we haven't visited for some time. We may have to make a small change, something that might only take a few minutes. The task gets allocated to one of our team, they open the project, make the change, build and WTF?!!!! What are all these build errors? That's be the toolset DLL's having been updated. A few minutes turn into hours as you trawl through the errors this forced upgrade has generated.

No, thanks, I'd rather have some control over DLL updates please. Stick these .refresh files. Can they be made optional in a later release? One mans meat ...

November 13, 2008 2:11 PM
 

marcelv said:

No, we only reported the problems we have with the referenced DLL's and we did not design this solution. That is still the job of engineers at Microsoft. As a matter of fact I am one of the guys that pushed very hard to get the web application projects back into VS. If you take a close look at when I wrote this post, you can see this was in the early days of VS 2005. At that moment in time, the ASP.NET team decided Web applications did not longer exist and we had to live with the web site projects! In that perspective the refresh files where something we absolutely needed to get things to work with cross solution references.

I am very strong against the use of web site projects just because of all the trouble they will cause you when working in a team. Those web site projects are really there for the hobbyists that want to maintain a simple website. It is not for professionals since they will get you in a whole lot of trouble. At our company we banned them for the projects we do. If you really want to fix your problem, you need to switch to Web Application projects instead.

Cheers,

Marcel

November 16, 2008 9:56 PM

Leave a Comment

(required) 
(optional)
(required) 
Submit
Powered by Community Server, by Telligent Systems