August 2005 - Posts
I am not sure what will be the result of the quest for another round of tests for Visual Studio, but I noticed that Microsoft has changed the status of the Feedback to 'Under Review' and 'Reopened'.
So still hope to expect an answer for the 224 (and probably more if you add the people who didn't voted).
And I am still waiting an answer from Scott Guthrie regarding the mid-term strategy fro VS 2005.
Update: Sorry I got it wrong it was reopened by the question starter.
If you are really serious fan of Windows Vista, you can use Universal Vista Inspirat Brico Pack 1.0 to transform your humble Windows XP with a new shiny look and feel. Tried it and like it :-)
(BTW thanks to have provided an Uninstall feature, always appreciated!)
So busy that I missed this new and very long comment from Marie Hagman, Visual Studio, Microsoft Program Manager on the Visual Studio feedback page for a Beta 3 release. Indeed where Microsoft is wrong is that we don't really want another Beta really, the main point is to know more about the future of VS 2005 service packs.
I also added below the comment from Clint (the guy who start this debate). What can I add to that? I don't like the word Postponed, seems like synonym to trashed.
You are absolutely right, if we find Whidbey quality is not ready for a Nov 7 ship we should and will delay shipping. We feel, however, that the product has reached that key inflection point where shipping the huge progress we’ve achieved brings far greater benefit to customers than further delaying to fix a few remaining issues that won’t impact most users.
We opened the Product Feedback Center last year with the release of Beta 1 to empower customers and as a result have received a lot of high quality feedback. We’ve fixed a very high percentage of reproducible customer reported code defects. As VS Client Dev Manager Shawn Burke writes “if you're filing bugs on MSDN Feedback that you really, truely, honestly believe are ship-stopping bugs, reactivate the bug and add your justification as to why you believe that. Write the scenario that's broken and why it's so important, or ask for more information about why it doesn't meet the bar. State that well, and the right things will happen.” See Shawn Burke’s full commentary on this on his blog - http://www.shawnburke.net/Default.aspx?document=264&userinterface=9
Over the course of the Whidbey product cycle we have modified shipping schedules and put new processes in place, to make sure our customer needs are addressed. There is always more to be done and no release is 100% bug free, especially with such a complex product as Visual Studio.
Visual Studio is over 43 million lines of code, there are over 30 teams working on different pieces, with roughly 700 developers checking-in code to 11 different virtual build labs that are then integrated on a rotating schedule producing over 100 different builds of the product daily. In addition we have interdependencies with SQL and MSDN. When we ship an official release like a Beta or RTM (release to market) we lock down and are code complete several months before the actual release date to allow for a final test pass, to stabilize and hit stress goals, then get the best bits to fulfillment for mass production of media. Before code complete there is a long list of exit criteria for the product that must be met, ensuring all key features and scenarios meet expectations. We have customer bug exit criteria to ensure high priority issues are fixed.
Why are we postponing so many bugs? As Shawn says “It's a massive balancing act: how do I ship quality software that will do the right thing for my users and still close it down and get it out the door with known issues? Is this paradoxical? For large software projects, at some point this becomes a treadmill. You could literally keep at it forever if you kept fixing all the bugs. Multiply this by the complexity factor…If you keep perturbing the system, you'll never get there, especially when it comes to sensitive things like stress results.”
Bug triage, where we determine priority and resolution of bugs, can be an unbelievably difficult process in which teams must reach consensus on issues where there are often conflicting considerations. Security, usability, accessibility, integration, would it be a breaking change, is it blocking or a build break… etc. Over 30 people from across the Division meet daily to discuss bugs and fixes ensure the right calls are made in team triage. The Product Feedback Center gives customers a new visibility into this process. You can see how your bug has been assessed against the triage bar and why Microsoft has made the decision to resolve it as Postponed, Fixed, or Won’t Fix. Decisions have been reversed based on customer comments and community vote. Bottom line is we are committed to shipping the right product and through the Product Feedback Center we have an even better sense of what that is.
Answer from Clint Stotesbery:
You point out some comments in Shawn Burke's blog at http://www.shawnburke.com/Default.aspx?document=264&userinterface=9
You can read my replies there too ( number 6 and number 9) rather than me repeating what I said.
Recently there was some new information released by Soma at his blog, http://blogs.msdn.com/somasegar/archive/2005/08/22/451026.aspx
Releasing an RC for VS and Beta 3 for TFS with a Go Live license is pretty close to what I suggested so this could probably be closed as Fixed. It would be nice to have the RC and Beta 3 available to non-MSDN subscribers though.
The only other issue that I think would benefit the community would be to have a statement regarding service packs for Visual Studio. Reintroducing service packs, and releasing one within 6 to 12 months of November, would make many developers less concerned about their issues. The community consensus seems to be that waiting 2-3 years for bug fixes (in form of another VS release) isn't acceptable.
So in summary:
1. Please make VS RC and TFS Beta 3 available to non-MSDN subscribers.
2. Please make a statement regarding reintroducing service packs for VS.
Proposed Solution: Put out a Beta 3 release at the end of September with a Go Live license for VS Team Suite, VS Standard/Pro, TFS, etc. Push back RTM if you have to. RTM December 31st or push it to 2006 (just keep the 2005 name then, no big deal).
Yes, people will complain about changing release dates but it isn't like this will be the first time. Developers won't care about when the RTM date was a few months after RTM if the product is full of bugs.
I am playing with a new online service called Pandora. This is still a Beta but hey this stuff is excellent.
The idea is that you can build your own ‘radio’ stations by picking for a start an artist or a song.
Then Pandora check their database and play not only the music you slect, but build the next selection on the same mood than the first.
So for example if you like The Beatles, a song from The Kinks, XTC or Fleetwood Mac can pop up, becuase they are based on the same key elements like vocals, or tempo.
Of course, you can tune up your selection and add more songs to refine the station.
Really excellent, kind of improved iTunes. What I really like is that it help me discovering some new music I never heard before, and a simple click will open straight away Amazon.
(At the moment works only by invitation you can request here)
CodeGallery, a community site where Microsoft contributors and customers alike can share and discuss their ideas and projects with other developers and IT professionals.
CodeGallery enables you and other .NET and Windows community participants to:
- Create a Micro-Community. Members can create a CodeGallery project, upload content such as binaries, source code, and whitepapers, customize their project portal with links to related projects, approve/deny membership requests, and generate online reports.
- Consume. At CodeGallery, you can search for, subscribe to directory updates (RSS), find useful scripts, tools, applications and other types of content, view recent project activity, and then download the best of what’s next in .NET applications such as PowerToys, tutorials, diagrams, and code.
- Contribute Feedback. Project members can discuss project contents using per-project message boards or log a bug against a project using integrated bug tracking tool.
- Refactor and Refine. Project owners can incorporate online community feedback into their offline development process and upload new releases for additional community input.
CodeGallery focuses on the conversation between developer and IT Pro customers and product teams and is distinct and different from gotdotnet Workspaces, which provides source control in addition to the features available in CodeGallery.
After so much bitterness it's time for me to join the camp of the happy adopters of VS 2005 (it doesn't mean I swallowed the pill anyway and I keep my right to rant if something goes wrong)
But finally most of current .Net web projects (about 57 !) are all happy campers under VS 2005. It has been a long and painful moment, but I manage to clear my way of all the hurdles of the migration path.
So few things I learned from my own experience:
- Use the latest migration DLL (see Scott Guthrie's post to download them).
- Don't think that the migration wizard is a kind of Harry Potter! No magic there so assume to have some manual work to do.
- It seems to be mandatory, at least with the Beta 2, to install all the tools on a CLEAN machine. I have a couple of free PCs around me so I am quite lucky, but I recommend absolutly to have a virigin Windows before installing the whole bunch. I am not yet totally sure about the why, but I can tell for sure that the migration doesn't work at all if all the DLLs messed up with some other tools. So I recommend to no having .Net 1.1 on the same machine (strange but it works much better with one framework only)
- Of course don't forget to install SQL 2005 first before Visual Studio 2005 if you don't want to lose more hair.
- Now if you have followed all the instructions,be patient (the installation process is TOO LONG!) time for some brainstorming. You need of course to keep a backup of your precious files out of the magic box. Then you need to think about the construction of your web application under VS 2003.
Example: I have a solution with 5 projects. One project is the main web application, the others referenced to some other projects elsewhere in your original machine.
- Copy all the files required for the conversion, don't bother to remove the Excluded files, it seems that the migration wizard manage them after all (but it doesn't exclude them in the Beta 2)
- For a successful conversion, if your web application has multiple projects, convert the solution not the projects.
- IMPORTANT! On your new machine create all the Virtual Directories you need before anything else, otherwise welcome to the broken heart club
- Then wherever you copy all your files edit your Solution file (.sln) with Notepad and check that all the paths (virtual or local) are correct and that you have all the projects required in your machine.
- Open VS 2005 and your Solution file, the migration wizard will fire, then you don't have to ask for a backup*, and voila! Finally your application should be converted with all the projects nested as before in VS 2003.
* Regarding the Backup option, well this were I got many problems because the backup folder is created under your Virtual Directory. So when you run your web project, you will have surely a lot of errors due to the duplication of the web config. It could be nice to see the backup by default out of the web root.
On the last point: this is omething I don't really understand, because I was ranting recently about the lack of web projects in VS 2005. But this is indeed what I wanted. My different projects are now exactly as they were in the previous version. So now I feel confused about all the fuss around this recently.
Hope this will help somebody.
Oh and last thing .NET 2.0 IS really FAST, yes really. I know it's only on my local PC, but I am loving it ;-)
UPDATE: Thanks Scott for your reply, even if I don't understand the timezone difference (good morning anyway). I still can't see my comment but no worry.
You mention a future post about some other questions people commonly asked about VS 2005. Great but does this include an answer about the update policy (service packs, patches, etc...) ? Believe me we need some answers on this :-)
Also I was finally able to convert successfuly one project with the new DLLs you sent me but nothing works well with one solution with multiple projects (6 in some cases). I will send you my feedback on this.
Scott I hope this is just a case of 'I click the button 'delete this comment I dislike' by mistake' !!
I really like the full explanation you give on the new web project system and other details with VS 2005, but I spend some long minutes to write a comment and yes it was positive. But you know me now I like to be a bit 'pushy'.
So why did you delete my comment? Now I noticed that your post contains only happy comments from happy customers. What's wrong with some positive and legitimate critics.
Of course I respect your freedom to do whatever you want with your blog, but this surprised me a lot.
Ireland .Net Developers Alliance 1st Birthday Conference
Dino Esposito, Paul Fallon, Ian Griffiths, Eamon O'Tuathoile
I invite you to join us in celebration of INDA's first birthday. To mark the end of the first year for INDA, we have organised a day long conference on 'Exploring cutting edge development in .Net Technologies'. It will take place on Tuesday 25Th of October in the Morrisson Hotel.
Sponsors are welcome. Contact me at webmaster at developers.ie
And a really cool solution using IFRAME (so not fully cross browser) and a thread.
The author Scott Cadillac suggest himself a future Ajax upgrade to remove the need for a specific browser.
Great! This is a really useful HTTP module (and free) you can implement in your web projects if you have to provide an upload facility.
SlickUpload is an ASP.NET HttpModule that provides scalable upload handling for ASP.NET applications. ASP.NET doesn't have any capacity to stream requests to disk, and thus will load an entire upload into memory before processing it. This can cause scalability problems, as well as opening up a possible vulnerability to a denial of service (DOS) attack. SlickUpload fixes these problems by intercepting the request before the ASP.NET page processing engine gets it, and streaming it in chunks directly to disk. This eliminates the problem of loading the request into memory. SlickUpload also provides rich progress and status information during the upload process, allowing an application to display upload status to the user in real time.
More Posts Next page »