DevDiv Servicing Team Blog

Earlier today DevDiv released 2 security bulletins as part of the monthly patch Tuesday cycle.

Microsoft Security Bulletin MS09-061 - Critical, Vulnerabilities in the Microsoft .NET Common Language Runtime Could Allow Remote Code Execution (974378)
Affected (DevDiv) products: .NET Framework 1.1 SP1, .NET Framework 2.0 SP1, .NET Framework 2.0 SP2.

More details about the versions affected by this vulnerability can be found in the security bulletin MS09-061. 

Microsoft Security Bulletin MS09-062 - Critical, Vulnerabilities in GDI+ Could Allow Remote Code Execution (957488)
Affected (DevDiv) products: .NET Framework 1.1 SP1, .NET Framework 2.0 SP1, .NET Framework 2.0 SP2, Visual Studio .NET 2003, Visual Studio 2005 SP1, Visual Studio 2008, Visual Studio 2008 SP1, Visual FoxPro 8.0 SP1, Visual FoxPro 8.0 SP1, Microsoft Report Viewer Redistributable 2005 SP1, Microsoft Report Viewer Redistributable 2008, Microsoft Report Viewer Redistributable 2008 SP1.

More details about the versions affected by this vulnerability can be found in the security bulletin MS09-062. 

Please remember that customers in the U.S. and Canada can receive technical support from Security Support or 1-866-PCSAFETY. There is no charge for support calls that are associated with security updates.

Thanks,
Jamshed Damkewala
Lead Program Manager, DevDiv SE Team

Hi,

It's been a while since the DevDiv Sustained Engineering (Servicing) team has posted to this space and we're mulling over resuming this provided we find appropriate topics and content to bring to you. We thought it would be a good idea to share with you what our team does and have you, our readers help us determine the type of topics/content you would like to see here.

So at a macro level here's what we do - we're a team of Release PMs handling the release of Hotfixes, security updates, and GDRs (general distribution releases) for DevDiv's flagship products - .NET Framework and Visual Studio.

Hotfixes - these are updates to the product that address very specific customer problems. Each Hotfix has a corresponding Knowledge Base Article (KB for short) which describes the issue addressed by that Hotfix. Customers can get these Hotfixes either by calling Customer Support Services (CSS) and for some select Hotfixes, by downloading these directly from Microsoft Connect or MSDN Code Gallery.

Security Updates -  these are updates that address issues that have brought to our attention by security reasearchers and other finders. Security updates are always documented in a security bulletin and these ship broadly to all customers and are available via Windows Update (for .NET Framework) or Microsoft Update (for Visual Studio).

GDRs - these updates are similar to Hotfixes, but they generally contain fixes that address scenarios shared by a large number of users and therefore we make these updates broadly available. A GDR might sometimes contain compatibility fixes or enable user scenarios that might have been partially supported when a product originally released.

Since security updates and GDRs are made broadly available, the quality bar for these is much higher than a Hotfix and we do much more testing on these in order to catch any problems and reduce the possibility of regressions.

To be completely transparent here, our team does not do all work that goes into each servicing update, many different teams contribute for each update. DevDiv uses a distributed servicing model where each team that ships functionality in the product is responsible for implementing fixes in their respective area of ownership. The centralized SE team (our team) is responsible for building and packaging the fixes, the setup and deployment aspects, and overall project management and coordination of the work across several teams.

Now that we have told you what we do, we're looking forward to your suggestions on what you would like to see on this page.

Thanks,
Jamshed Damkewala
Lead Program Manager, DevDiv Sustained Engineering Project Management and Release Team

Hello folks,

As you might have noticed the name of this blog has been updated to reflect the change in the internal name for our team. The DDCPX team is now part of the DDE (DevDiv Engineering) team.

We have a new name for the team, but our mission remains unchanged - help you, our customers develop the very best software using our tools. So keep writing and telling us what we are doing well, and where we could do better.

Regards,
Jamshed Damkewala
Security Program Manager, DevDiv

This one certainly covered a bunch of ground, people and calendar time. Special thanks to Natalia and Michael from DDCPX QA for outstanding performance and diligence in their respective areas. PMs, QA and Devs on all product team were instrumental in helping us ship a release that is demonstrably more stable to our customers. 

I also want to offer a huge thank you to customers that actively participated in the beta program earlier this year. Your feedback and work exercising the included fixes were invaluable.

We held it a bit longer than planned for very good reasons and those customer that continue to rely on the VS 2003 can continue working with an even better tool. There have been many lessons learned which will be put to good use improving DDCPX processes and practices. Thanks again to all customers who participated in the beta or got feedback to us through other channels.

The fix list KB article (918007) is not yet available on the web and we’re working to get that published as soon as possible. In the meantime here are links to the patch and release notes.

Regards,

Lee Coward

Visual Studio 2003 SP1 Program Manager

Update: fix list KB article is live.

Visual Studio .NET 2003 Service Pack 1 is just about ready. Very near the end of our sign off testing a bug was found in the VC Runtime that we felt important to get into the Service Pack for customers. This change resulted in a new round of testing and has moved the release date to August 15, 2006.

Almost there!

Lee Coward

Program Manager

Visual Studio .NET 2003 SP1

A common complaint when doing code reviews with TFS is that people think they have to Unshelve the shelveset to review the code. They really want to see what changed in a file that is being checked in and they can’t find a way to do it. They typically wind up unshelving the shelveset and reviewing each entire file contained in the shelveset.

There is actually a way to view individual files from a shelveset or to compare an edited file with another version.

In the Unshelve dialog box, either select the shelvest and click Details or double click the shelveset name. This will bring up the Shelveset Details form. In this form, you can:

1. Double click on a file name to open it in Notepad
2. Select a file and click one of the icons in the tool bar. There are icons which will open the file in Notepad or compare revisions of the file. For new files (i.e. those with a change status of add), the comparison icon is grayed out.
3. Right click on a filename which will bring up a selection box. In this box, you can click View which select will open the file in Notepad or Compare and a file version with which you want to compare the file being code reviewed. For new files, you cannot select Compare because the file revisions to compare against are grayed out.

When comparing revisions of a file, the Unmodified and Latest versions are always available for files which were edited. If you have an edited version in your workspace, you can compare the changed file against your version too.

John D'Addamio

From Joe Morel's Blog:

One of the most difficult parts of ASP.Net 2.0 application creation is configuring your site correctly.  It’s easy enough to actually set the settings, but how do you know the settings are correct?  What are the best practices for ASP.Net site configuration, and how do you check that your site is following those practices?

Announcing the Best Practice Analyzer for ASP.Net!  It’s currently just an alpha preview version—a shell of the application we hope to turn it into, but it should give you an idea of what we are thinking about.  The tool scans the settings for your ASP.Net application from your machine.config, root web.config, and site web.config files and notifies you of any potential errors, warnings, or suggestions to make your site configuration better.

We only have a few rules right now in the engine—this release is mainly to get feedback from the community and see what you think of the tool, but also to start gathering rules from the community.  What best practice for ASP.Net configuration do you have to share?  Let us know by leaving a message in our forum!

Sharing is the name of the game for this tool—this tool will be part of the Power Toys for Visual Studio, and the libraries we are using to make this an ASP.Net 2.0 focused tool will be 100% Shared Source!

Download the installer for the tool here.

Let me know what you think, and send some good rules for ASP.Net configuration!

Hello all,

I am gathering Rules/Best Practices recommended when developing ASP.NET applications and services. The intention is that we will ship a tool (Power Toy) that performs the analysis on your web sites that you could also extend to include new rules. Whether gained through personal experience or learned formally, I would love to hear your suggestions for default rules.

Context

The context to which I’m speaking of is with the .config files (machine.config and web.config) associated with ASP.NET projects. i.e what settings should and should not be made in said files.

Examples

EnableSessionState = false. Set in web.config for all pages that don’t utilize session data. Enable only when necessary.

AutoEventWireup = false 

Suggestions in all areas, not limited to the following, are welcome.

• Performance
• Security
• Presentation

Thanks

-Ifeanyi Okpareke (After Market Solutions Team)

Among the most confusing stories that we have asked .NET Framework customers to understand has been .NET Framework 1.1 support on Windows Server 2003 and 64-bit versions of Windows. We've blogged about this before. Today we get to tell you that we've done right by putting .NET Framework 1.1 servicing releases on Windows Update for 64-bit platforms.

Microsoft releases security updates on the second Tuesday of every month and Windows Update releases non-security updates on the fourth Tuesday of every month.  Well, today is the fourth Tuesday in March and we went live with .NET Framework 1.1 Service Pack 1 on Windows Update for supported 64-bit versions of Windows.  Additional content targeting .NET Framework 1.1 Service Pack 1 on these same systems will go live on April 11.

None of these are new releases; they are the exact same binaries that are already on Windows Update for .NET Framework 1.1 running on 32-bit Windows operating systems and have always been available for supported 64-bit Windows operating systems on Download Center.  What's new is that now if you have .NET Framework 1.1 installed on your x64 or supported Itanium version of Windows then you can keep that .NET Framework 1.1 installation up-to-date using Windows Update, SUS, and WSUS.

It should be noted that there do exist performance issues running .NET Framework 1.1 on Itanium-based systems (here).  There is also a known compatibility issue between ASP.NET 1.1 (a component of the .NET Framework 1.1) and IIS 6.0 on 64-bit versions of Windows (here).  These are known issues and the current announcement does nothing to mitigate these concerns.  Rather, we assume that if you have the .NET Framework 1.1 on a 64-bit Windows system then you have already evaluated and addressed these concerns for your environment.

The supported operating systems are the following:

• Windows XP Professional x64 edition
• Windows Server 2003 x64 editions
• Windows Server 2003 for Itanium-based systems w/ Service Pack 1

A key goal of the community work at Microsoft is putting a face on this software empire. One way to accomplish this is to let you literally see us.

At the end of our first SCRUM sprint, about six weeks ago, we taped a Channel 9 video where we demo'ed MSBee, Managed Stack Explorer, and the TFS Administration Tool along with some fun banter. Since there's a long line to get onto the Channel9 home page (unless you're Bill Gates), you can watch our Oscar caliber performances here.

BTW, Hi Mom!

- Craig

Updated binaries have been posted on GotDotNet for the TFS Administration Tool, making the tool compatible with the most recent version of Team Foundation Server (the Release Candidate).  The new release also fixes a bug where the tool would crash if a user had more than one role in TFS.  The new binaries can be downloaded here:

http://go.microsoft.com/fwlink/?LinkId=59385

Joe Morel

Fast on the heels of the MSBee CTP, I'm pleased to announce the availability of the TFS Administration Tool Beta 1.

For anybody who has used any of the betas or CTPs of Team Foundation Server, you are probably aware of the pain around user administration.  Simply put, a TFS administrator must add users (and their appropriate permissions roles) in TFS, Sharepoint, and SQL Reporting Services servers separately to completely setup their TFS installation.  This process is time-consuming at best and downright confusing at worst.

I originally blogged about whether or not a tool to solve this pain point was worth pursuing a couple of months ago.  From the feedback we received on that blog post, and the MSDN Product Feedback Center suggestion filed for such a tool, we decided to create the tool as a Visual Studio Power Toy.

Please check out the GotDotNet CodeGallery site for the TFS Tool, which includes a download link and a place where you can file bugs that you find in the tool with us here at Microsoft.  (This tool should be posted by 5:00 PM PST today, 2/10/2006.)  After the final release of this tool, which we are planning to coincide with the final release of TFS, we will release the source code for this tool as a Microsoft Shared Source solution.

If you have any questions about the tool, please leave a comment in this blog or check out our Aftermarket Solutions Forum on the MSDN Forums.  A big cheer should go out to Kannan Sundararajan, the lead developer on this tool...great work!

Joe Morel

Program Manager