Microsoft Windows SDK Blog : setup

Windows 7 SDK Setup: common installation issues and fixes

wsdkblog@microsoft.com — Wed, 16 Sep 2009 23:05:00 GMT

This post describes common installation problems with the Windows SDK for Windows 7 and .NET Framework 3.5 SP1 (released August 2009), and workarounds for each issue. The Windows SDK for Windows 7 is available for download in both ISO and Web Setup format. Web setup allows you to install a specific subset of the SDK you select without having to download the entire SDK. The DVD ISO setup allows you to download the entire SDK to install later.

Error:

During the installation of Windows SDK you receive an error similar to

An error occurred installing the Microsoft Windows SDK for Windows 7 package. Error: A file that is required cannot be installed because the cabinet file.

Or

Cabinet file does not have correct format

Cause:

This error usually occurs when you have a bad download of SDK Components or corrupted files.

Solution:

Running the Windows SDK web setup on some connections can sometimes have issues when downloading the files. We recommend that you clear the %temp%\sdksetup directory and retry your web setup. If that fails, switch over to the ISO setup for the Windows SDK.

For Windows 7 SDK please refer to the download page here http://www.microsoft.com/downloads/details.aspx?familyid=71DEB800-C591-4F97-A900-BEA146E4FAE1&displaylang=en

Error:

When using Web setup to install Windows SDK, you might receive an error similar to

"Unable to find the file SDKSetup.cab at the installation source. The most likely..."

Cause:

This error usually indicates a problem with underlying proxy issues or problems with network connection.

Solution:

Verify your network connection and try to install the SDK again. If the problem persists, download the ISO instead of using the Web Setup.

Error:

During the Windows SDK installation you encounter an error similar to

"A problem occurred while installing selected Windows SDK components.

Installation of the "Microsoft Windows SDK XXXXXX" product has reported the following error: Fatal error during

Installation."

Cause 1:

You are installing Windows SDK to a non fixed physical hard drive like a RAM/USB hard drive.

Solution:

Please change the install location of the Windows SDK during install options and install Windows SDK to a fixed physical hard drive.

Cause 2:

Network Connection is lost during installation when using web setup.

Solution:

Re try the Windows SDK installation and switch to ISO install if the problem persists.

Cause 3:

User cancelled the installation

Solution:

Reinstall Windows SDK either from Web Setup or ISO downloads.

Error:

During an attempt to install Windows SDK you receive an error similar to

A problem occurred while installing selected Windows SDK components.

Installation of the "Microsoft Windows SDK for Windows 7" product has reported the following error: Please refer to Samples\Setup\HTML\ConfigDetails.htm document for further information.

Cause:

This error usually occurs when you have a corrupted Document Explorer installation.

Solution:

Uninstall the document explorer and re try the Windows SDK Installation.

If uninstalling Document explorer fails with errors similar to “Unable to open key” please refer to the solution explained here to uninstall Document Explorer.

Error:

When installing using an ISO download you receive an error similar to

“Setup could not find the file WinSDK_amd64\WinSDK_amd64.msi at any of the specified source locations”.

Cause:

This problem usually occurs when you are installing from an ISO build for a different architecture.

Solution:

Windows SDK now have different ISO’s for different architectures. Please download the correct ISO based on your system platform and architecture type.

Error:

An attempt to install Windows SDK might fail with the following error

A problem occurred while installing selected Windows SDK components.
Unknown product: {E28FB85C-8E3E-4E12-B1E6-58A3AFC0AFB4}
Parameter name: productCode

Cause:

Document Explorer has shared component dependencies which break if you delete VS 2008 or Windows SDK files/registry entries manually. If these Files/Registry entries are deleted manually, Document Explorer installer will not be able to access its installer components.

Solution:

Uninstall Document Explorer and retry installing Windows SDK. If you are experiencing problems uninstalling Document explorer please refer to the blog post here http://ctrlf5.net/?p=184.

Error:

An attempt to uninstall earlier Versions of Windows SDK may fail and Windows SDK setup reports error similar to

“Unable to find required source files in any of the source locations”.

Cause:

Some earlier versions of Windows SDK like the Windows SDK for Windows Server 2008, require source files to be able to uninstall the SDK. Windows SDK for Windows 7 does not require the source file to be able to uninstall.

Solution:

1.       Download installer cleanup utility from http://support.microsoft.com/kb/290301

2.       Select All Windows SDK related packed with the version number you are trying to remove.

a.       Also select VCRedist and Document Explorer packages with the Windows SDK Version number. Do not select VcRedist/Document Explorer packages that have a different version number

b.      Also Select Windows SDK .Net Development tools (It has .Net version number, something like 3.5.XXXXX)

3.       Remove the selected packages

With this method, you will remove the installer cache, but the physical files remain on the disk. These will mostly get overwritten by the latest SDK but the behavior is not guaranteed.

Error:

When installing Windows SDK, you receive an error similar to

Unable to install Microsoft Visual C++ (error 1935)

Cause:

Usually this error occurs when files required by the installer are in use. Most probably the mscoree.dll is in use.

Solution:

Close all the application that are already in use and try the Windows SDK Installation again.

Finding Errors from the SDKSetup log:

On each install and uninstall session, SDKSetup creates a descriptive log in the System %temp% folder. (Usually it is C:\Users\UserName\AppData\Local\Temp). When an error occurs during the Windows SDK installation or un-installation, a more descriptive error message is logged towards the end of the log file. The current log file is named similar to SDKSetup_7.0.7000 1800.log and changes based on the Windows SDK you are using. You can also search for “error” within the log to verify if there are another errors during the installation. Ignore messages similar to ‘ErrorDialog = ErrorDialog’ and “Error Status: 0”.

Nanda Lella
Software Development Engineer
Windows C++ & SDK Team

Send your thoughts to the Windows SDK Feedback alias. Tell us how you use the SDK and what we can do to improve your development experience.

The MSDN Windows SDK Developer Center is the place to find resources and links to Windows SDK products, release notes, technical articles, and more.

Troubleshooting Windows 7 SDK Download/Install

wsdkblog@microsoft.com — Tue, 11 Aug 2009 01:51:00 GMT

This article applies to the Windows SDK for Windows 7 and .NET Framework 3.5 SP1. Read these other posts to troubleshoot issues with the Windows SDK for Server 2008 and .NET Framework 3.5 or to troubleshoot issues with the Windows SDK Update for Vista and .NET Framework 3.0.

The Windows 7 SDK is available for download in ISO or Web Setup format. Web setup allows you to select a specific subset of the SDK so you do not have to download the entire SDK. The ISO setup allows you to download the entire SDK to burn to disk or a virtual drive, and install later. This release provides three platform-specific ISOs. Choose the ISO that matches the CPU platform (x86, x64, or Itanium) that you are installing on. If you are having problems downloading the correct ISO from the Microsoft Download Center, use these direct links:

Running the Windows SDK web setup on some connections can sometimes have issues when downloading the files. We recommend that you clear the %temp%\sdksetup directory and retry your web setup. If that fails, switch over to the ISO setup for the Windows SDK.

Typical %temp%\sdksetup directory:

On Windows Vista or Windows 7: C:\%user%\AppData\Local\Temp\ SDKSetup_7.0.6918.0.log
On Windows XP: C:\Documents and Settings\%User%\Local Settings\ SDKSetup_7.0.6918.0.log

Get the Web Install of the Windows SDK for Windows 7 http://www.microsoft.com/downloads/details.aspx?FamilyID=c17ba869-9671-4330-a63e-1fd44e0e2505
Get the ISO Downloads of the Windows SDK for Windows 7 http://www.microsoft.com/downloads/details.aspx?FamilyID=71deb800-c591-4f97-a900-bea146e4fae1

About ISO image files

Many products are posted as ISO image files. An ISO file is an exact representation of a CD or DVD, including the content and the logical format. ISO files end with an .ISO extension. The most common use of an image file is to write it to a blank CD-R or DVD-R. ISO image files can also be opened and their contents copied to a local folder, much like ZIP files. ISO files may also be virtually mounted and accessed as a device. These two methods of using ISO images are described below.

Copying the contents of ISO files to a drive

The contents of image files can be used as virtual discs using utilities such as ISObuster, Daemon Tools or Virtual CloneDrive for Windows. Using this method you can extract the files from an image file to a temporary folder on your hard drive, then run setup.

Writing ISO files to CD-R or DVD-R

Most CD-R/DVD-R writing software includes a feature to create a disc from an image file. Note: you must use the special "copy image to CD" or "burn image" functionality. See your software’s Help for detailed information. Common utilities for writing ISO file to recordable media such as DVD-R include Nero and Roxio. In Windows 7, you can burn and ISO by right-clicking the .iso file and selecting “Burn disc image”. After a CD/DVD-R has been written, you should verify that the file was successfully written. Many freeware programs are available for calculating the SDK SHA-1 hash value. Use an Internet search engine to search for “sha1 hash” to find a freeware program. Windows SDK for Windows 7 verification information:

File Name: GRMSDK_EN_DVD1.iso
Chip: X86
CRC#: 0xCA4FE79D
SHA1: 0x8695F5E6810D84153181695DA78850988A923F4E
================================================
File Name: GRMSDKX_EN_DVD1.iso
Chip: AMD64
CRC#: 0xB417A4F7
SHA1: 0x3393C98B8468CB3505557854922707510F8B65E1
================================================
File Name: GRMSDKIAI_EN_DVD1.iso
Chip: Itanium
CRC#: 0x5E0E4BEA
SHA1: 0xAE454215585A044EBE593E9F71FF1A4BC03D56A8

Other Resources

Windows SDK Online Release Notes http://download.microsoft.com/download/8/8/0/8808A472-6450-4723-9C87-977069714B27/ReleaseNotes_Win7RTMSDK.Htm

Windows SDK blog http://blogs.msdn.com/windowssdk

Windows SDK MSDN Developer Center http://msdn.microsoft.com/en-us/windowsserver/bb980924.aspx

Windows SDK Developer Forum http://social.msdn.microsoft.com/forums/en-US/windowssdk/threads/

Troubleshooting: Uninstall SDK components

wsdkblog@microsoft.com — Fri, 01 Feb 2008 21:51:00 GMT

This article applies to the Windows SDK for Windows Vista, the Windows SDK for Windows Vista Update, and the Windows SDK for Windows Server 2008 (a pre-release SDK at the time this post was written).

The Windows SDK installs both SDK-core components and “shared” components created by other teams at Microsoft as separate MSI files (see below for more on MSIs). When you select to uninstall the SDK through Add/Remove Programs (Programs and Features on Vista), most of the SDK will be uninstalled automatically. However, a few components might need to be uninstalled separately in order to remove all SDK components.

· Microsoft Windows Software Development Kit -- the SDK core-component files

· Microsoft FxCop 1.35 -- .NET code analysis tool installs with the SDK and also with Visual Studio

· Microsoft Document Explorer -- document viewer tool installed by both Visual Studio and the SDK

· Microsoft Visual C++ Compilers 2008 Standard Edition – compiler package installed by the SDK and/or Visual Studio 2008

You may have installed some of these applications with another product besides the SDK, such as Visual Studio or SQL Server. Removing shared components will make those components unavailable for other applications that may use them, so think twice before uninstalling them. For example, Visual Studio has a dependency on Document Explorer (DExplore.exe), the document viewer used to display Help and other documents.

If you uninstall a component that other applications has a dependency upon, such as Document Explorer, it will not be available for that other application and you’ll receive an error message when you try to launch the app. But don’t worry. If you uninstall a component by mistake, you can easily run a Repair of the application that requires it: Control Panel, Programs and Features (Add/Remove Programs on pre-Vista OSes), select the application that is not working correctly, click Repair at the top of the Programs and Features window.

What is an MSI file? MSI files are Microsoft Windows Installers. MSI files offer more flexibility when installing programs. For example, Windows installers allow you to repair your current installation instead of having to uninstall and reinstall a damaged program.

Troubleshooting SDK Download/Setup Problems

wsdkblog@microsoft.com — Sun, 02 Sep 2007 08:28:00 GMT

Having trouble downloading or installing the Windows SDK? Here's help.

Most common issues

Also if you are trying to install Windows Vista RTM SDK (build 6.0.6000.16384, released November, 2006), you should try installing the more recent Windows Vista SDK Update (Build 6.0.6000.16386, released in February, 2007):

Microsoft Windows SDK Update for Windows Vista Web Install:

http://www.microsoft.com/downloads/details.aspx?familyid=4377F86D-C913-4B5C-B87E-EF72E5B4E065&displaylang=en

Microsoft Windows SDK Update for Windows Vista ISO Install:

http://download.microsoft.com/download/4/2/6/42684501-9ec5-43dd-9dfe-c8c9dfa6a66f/6.1.6000.16384.10.WindowsSDK_Vista_Feb2007Update_rtm.DVD.Rel.iso

Windows SDK Update for Windows Vista ISO verification information

For more information on how to use this information to verify that your ISO download is not corrupt, see Testing CD-Rs and DVD-Rs, below.

· AutoCRC: 0x9863D5EC

· Size: 1.15 GB (1,237,436,416 bytes)

· SHA-1 hash: 0x5D28463DAAA755450D697C850DD622D1F8B580AE

What are ISO image files and how do I use them?

Many products are posted as ISO-9660 image files. An ISO image file is an exact representation of a CD or DVD, including the content and the logical format. The most common use of an image file is to write it to a blank CD-R or DVD-R, resulting in an identical copy of the original disc including file name and volume label information. ISO image files may also be opened and their contents copied to a local folder, much like ZIP files. ISO files may also be virtually mounted and accessed as a device. These three methods of using ISO images are described below.

Writing ISO files to CD-R or DVD-R

Testing CD-Rs and DVD-Rs

After a CD/DVD-R has been written, you should verify that the file was successfully written. Many freeware programs are available for calculating the SDK SHA-1 hash value (provided above). Use an Internet search engine to search for “sha1 hash” to find a freeware program.

Copying the contents of ISO files

The contents of image files may be accessed directly using third-party tools. Using this method you can extract the files from an image file to a temporary folder on your hard drive, then run setup. The following tools (and others) offer image file support:

Still having problems?

Please send your install log to wsdkfdb@microsoft.com so we can help you troubleshoot. By default, the log is installed to:

· On Vista:

C:\%user%\AppData\Local\Temp\SDKSetupLog.txt

· On XP:

C:\Documents and Settings\%User%\Local Settings\ SDKSetupLog.txt

Can I install the Windows SDK in quiet mode?

wsdkblog@microsoft.com — Fri, 03 Aug 2007 08:05:00 GMT

If you’ve tried to install the Windows SDK from a command line in quiet mode using setup.exe /q you have probably found that it’s not supported. Users are required to view and accept the Microsoft EULA during the installation, and that's not possible via a command line setup.

Windows SDK Team

Send the Windows SDK Team Your Thoughts

wsdkblog@microsoft.com — Thu, 26 Jul 2007 20:35:00 GMT

Do you have feedback for the Windows SDK? We want to hear from you. Email your feedback to us. The Windows SDK provides all of the necessary headers, libraries, and tools needed to build Windows applications that make use of the Win32 API set and the .NET Framework, and includes samples to illustrate the technologies for those platforms. What do you like? What do you dislike? What should we change next time?

The Windows SDK Side by Side story

wsdkblog@microsoft.com — Fri, 15 Jun 2007 00:55:00 GMT

Beginning with our next public pre-release of the Windows SDK for Windows Server 2008, the Windows SDK will begin installing on a Side by Side basis. What does that mean for you? Right now, not very much. But by the time the next versions of Visual Studio and Windows Server are on your computer, it should make our SDK easier to use, manage and customize.

First, let me give you a little history that should help you understand what we’re doing and why. The Windows SDK was brought together in 2005 as the combined Platform SDK (PSDK) and .NET Framework SDK, encompassing both native and managed code development. It was a herculean task that resulted in a very high quality product. The next step was to manage our future SDK releases. Immediately on the heels of that first Windows SDK product in November 2006, we prepped to put out our Japanese product and our Update product. Though we had tentatively planned to share SDK components between those products, we opted due to time constraints to allow users to only have one of those three releases installed. In other words, if you install the Update and have the November 2006 release installed, you have to remove the November release before proceeding.

The other products we really started to work on are our releases for the next versions of Visual Studio and Windows Server. The blocking scenario discussed above didn’t work at all for those SDKs. For one thing, much of our work around the Visual Studio release is to get our MSIs chain installed with the VS install. If we had added a dependency on the user uninstalling the Windows SDK every time they installed VS, we would be considered as breaking VS, not a good thing.

Therefore the solution was to install the SDK versions side by side. This means that you can have multiple SDKs installed at the same time. It’s possible to have all of these installed in parallel with each other:

PSDK February 2005 release
NET Framework SDK for .NET Framework 2.0
SDK for Windows Server 2003 R2
Windows SDK November 2006
SDK content for Visual Studio 2008
Windows SDK for Windows Server 2008

You will always have the option to remove any or all of these releases, but we felt that allowing you to have each of these installed would give you the maximum amount of flexibility and customizability.

“Okay, Jason, I get this, but what about the specifics?”

Each release has:

Separate install directories
Separate Start Menu entries
Separate RegKeys
All common content is installed twice

And what will the install directories be?

Windows SDK for Windows Vista

\Program Files\Microsoft SDKs\Windows\v6.0

Windows SDK Visual Studio 2008 Components

\Program Files\Microsoft SDKs\Windows\v6.0A

Windows SDK for Windows Server 2008

\Program Files\Microsoft SDKs\Windows\v6.1

Windows SDK for future updates to Windows Server 2008

\Program Files\Microsoft SDKs\Windows\v6.1A

Windows SDK for the next version of Windows

\Program Files\Microsoft SDKs\Windows\v7.0

Why that naming scheme?

The first number is the major OS number. The second number is the minor OS number. The third number is the SDK increment.

We're interested in your feedback on this issue. Please post your comments and questions.

Jason Sacks
Setup PM, Windows SDK

Reference Counting, Side by Side installation and the Windows SDK

wsdkblog@microsoft.com — Wed, 04 Apr 2007 00:56:00 GMT

One of the most interesting challenges for me as a member of the Windows SDK team is that we ship so many products. Between Betas, CTPs and RTM releases, I’ve probably been part of at least a dozen releases since I joined the team in June 2005, and we have three more major releases in the pipeline for 2007. What’s extra complicated about that is that each of the releases has their own unique sets of content. How do pre-release SDKs live alongside released SDKs? How does each RTM SDK treat each other RTM SDK? How do we manage our content when multiple copies of the same content are installed by different products?

As the Setup Program Manager for the SDK, it’s my job to worry about things like these. I’ve created a matrix that shows the expected behaviors when products are installed one on top of the next, but the matrix is, by its nature, massively complex. My spec that lists the scenarios around this has 16 different scenarios listed, and I’m constantly concerned that I’ve missed one or two key scenarios.

Thankfully, the scenarios for install boil down to a few clear rules. We decided early on that pre-release and RTM versions of the SDK must live side by side on the user’s machine. A pre-release can never overwrite an RTM version; otherwise, the users would have release-quality content overwritten by Beta content. That’s obviously a bad, bad scenario. Another rule is that when the user has an SDK that has almost the same content in it – as in when the user has one of the three versions of the Windows SDK that are almost the same (the RTM SDK, our SDK Update or our Japanese-language version of the SDK) we just ask you to uninstall one SDK before installing another.

That solution works, but, to me, it’s not the perfect solution. The better solution to me is something called Reference Counting, or RefCounting. RefCounting is a MSI Custom Action which we use to track which content is installed by which application. If the content would be installed by more than one version of the SDK, we don’t install it more than once. Instead, we simply track that more than one application has installed the content.

As an example, if you installed the Windows SDK Tools for the .NET Framework through Visual Studio “Orcas” and also through an install of the SDK, the tools won’t be installed twice. They’ll be dropped to disk once, and the Setup Custom Action will write a registry key to note that the file was installed by both apps. In that way we prevent disk sprawl and also prevent users from breaking one product when uninstalling another product.

RefCounting is generally thought of as applying to uninstallation, but we use it to help with our install story as well. We get installation detection from the way we deal with product codes in the SDK MSIs. If the same product code for an MSI is in place, the MSI simply doesn’t get installed. At the same time that install is skipped, the RefCounting Custom Action also writes to the registry that another product is sharing that MSI. At uninstall, then, RefCounting queries the Registry and sees what apps have used that MSI. If more than one installed SDK uses that MSI, the MSI stays on disk while the product is simply RefCounted down by one iteration.

This process is crucial to our hopes of producing multiple localized Windows SDKs for future SDK releases. If we were to release an SDK with Japanese content and at the same time release content in some of the other Visual Studio-supported languages, it would create massive disk sprawl. Instead, through this scheme, we’ll be working to enable to allow you to install multiple versions of the .NET Framework documentation while only installing only one version of the Win32 samples.

It would help our decision making a lot if you gave us an idea of how you manage content on disk. Would you expect more than one copy of the same content to be installed, or would you prefer one copy? When do you expect our setup to upgrade for you, and when would you expect it to install side by side?

Jason Sacks
Setup Program Manager, Windows SDK

Windows SDK: How and why we collect installation information, part 2

wsdkblog@microsoft.com — Tue, 24 Oct 2006 22:47:00 GMT

With my post from earlier in the week as a background, I wanted to share with you how the Windows SDK is collecting CEIP-conformant data on usage of our product, and what our future plans are around gathering data.

We've separated our implementation of CEIP into two phases . The first phase will be implemented in the upcoming full (RTM) release of the Windows SDK for Windows Vista. In this phase, we're collecting two pieces of user data around setup: How well the installation itself goes, and what custom install options you choose.

To test the quality of setup, we take two data points. First we get a datapoint that setup starts and then we get a second datapoint indicating whether it completes. These datapoints are built on top of existing code for ease of implementation. For instance, our setup application already logs 13 different ways that a setup can complete. We simply take note of those conditions and upload them to the CEIP database. Among those conditions are:

ERROR_SUCCESS = 1
ERROR_PRODUCT_INSTALL_FAIL = 2
ERROR_INVALID_ARGUMENTS = 3
ERROR_MISSING_DEPENDENCY = 4
ERROR_INSUFFICIENT_PRIVILEGES = 5

A small binary file containing that information is created on the user’s %temp% folder as setup runs. At the close of setup, all users are shown an opt-in CEIP check box . If users leave the box as unselected, the information is simply purged from the %temp% folder. If the user selects the box, the file is uploaded to CEIP’s secure server and then is discarded. In either case, the content is purged from the user’s machine.

In the database, each of those datapoints are logged as discrete bits of data. From that data, we are able to cross-reference the information and begin to be able to answer some questions that we’ve wondered about for a long time. For instance, from the 13 points mentioned above, we can answer questions like "how many of our users who start install complete the install?" or “how many of our users have a network failure on install? Right now we only have anecdotal evidence to give us that information. These datapoints will give us real world information that will us understand the sorts of problems that users are running into and allow us to build a better setup. (Though, of course, we hope that most of the results show that users are getting ERROR_SUCCESS, which I think is my favorite error message ever.)

The second half of our data collection project for our upcoming release of the SDK is to track the state of each of the custom install options our users choose. We give users about sixteen different options on the Install Options screen of setup, but we don’t know how many users are actually choosing those options. Do most users simply take the default settings, or do they like to pick and choose?

Each of these datapoints are being collected so that we can drive better implementation decisions in the future. If most of our users are selecting all custom setup options, or if we find that many users are deselecting FxCop or selecting to install the .NET Compact Framework, that will allow us to make appropriate decisions about what is selected by default in the future to meet the needs of the majority of our users. Sure, the numbers will still be affected by the number of users who opt in to sending their data, but at least we'll be getting a much broader amount of real world user data than we have been.

For the post RTM phase, we're still trying to decide what questions to track. The driving factor in asking these question is to allow the SDK team to determine where to focus our energies.

We also are wrestling with the question of how to get information on more issues than just setup. Setup is a good first place to gather information since the SDK team controls all of our setup code, but it would be great to be able to track information on how you use other parts of the Windows SDK. We still have a lot of work to do around choosing approaches in those areas before we decide what to do there.

We're really interested in your feedback, and we believe we can build a better product if we have data about how the Windows SDK is being used. Please comment to this blog if you have questions or feedback about CEIP or how the Windows SDK implements it. I hope at a minimum that you’ll consider clicking the checkbox on the final install screen that says “Help improve our products by sending your installation report to Microsoft. No information collected is used to identify you or contact you." You can influence the future direction of the SDK simply by clicking one little checkbox.

Install options in the Windows SDK

wsdkblog@microsoft.com — Mon, 11 Sep 2006 20:12:00 GMT

I’m pleased to announce that the online version of the RC1 Windows Vista SDK docs are live!

We are working on Vista RTM and making plans for Visual Studio “Orcas”.

Moving into the “Orcas” time frame, one of the areas we have been discussing is the Windows SDK install options.

When you install the Windows SDK, you can install the whole thing or optionally you can install a subset of the SDK. For example if you just work on Win32 C++ applications, you can install just the Win32 and COM portions of the SDK. There might be a few benefits of installing a subset of the SDK. Some possible benefits are that the SDK downloads faster, the download is more likely to succeed, searching either manually or using a search program is likely to be more accurate, faster and use less computing resources. Of course, in some scenarios installing a subset might not be the right choice.

If having the option to install a subset is helpful for some people, which options should exist? Should we have options to install a subset for native developers that use Win32 and COM, a subset for .NET Framework users (this exists today)? Maybe a Web option would be nice for some folks as well. Are these even the right way to think about install options? Perhaps the options should be completely different, more like C#, Visual Basic .NET, and C++. Should the Visual Basic option include content that only applies to Visual Basic or to any .NET program? How many options should we even have? I advocated for users being able to create their own install options, like just Visual Basic reference about Web development with ASP.NET, but this might be confusing for many customers.

Another thing we discussed this week is the class library. The class library contains reference documentation, which includes a description of the parameters and return values for members. Today we organize the .NET class library and the Win32 and COM class libraries differently.

The class library in the .NET Development section contains reference for most managed types – they are pretty much all in there. The logic behind grouping them together is that all of these topics are similar in that they are managed reference. They look the same and have the same type of information. If you write .NET managed code, it is also likely that you will use managed types in combination with managed types from other technologies.

This is not how we organize the Win32 and COM section reference. We could have the managed reference grouped with the technology. For example instead of the having the reference for the System.Data types in the class library in the .NET Development section, we could move it to a location along with the other ADO.NET documentation. This is nice when you want to see all the classes in ADO.NET, but it gets annoying when you want to see the reference for a type not in the System.Data namespace and have to try to find it in another section of the SDK. We absolutely don’t want to make it harder to find the right content!

If you have an opinion about these topics or anything else related to the Windows SDK, we can make changes. Now is a great time to let us know what changes you would like to see.

Sean Grimaldi

Custom install locations - what do you think?

wsdkblog@microsoft.com — Fri, 07 Jul 2006 20:17:00 GMT

In the June CTP, we delivered custom install locations in the Windows SDK. Have you folks seen it? If so, what do you think of it? Have you run into any problems or issues with it? Any suggested changes to the page design or format? This is a great chance to get involved with helping to influence how the SDK team implements this function. We created the screen after quite a bit of design discussions within our team, but we'd like to know if the decisions we made seems logical and usable by you.

And if you didn't use the install locations when installing June CTP, why not? Did you choose any custom install options? We're planning on adding metrics tracking for these issues, but we're also curious to hear your anecdotal evidence on what you do and why.

Jason Sacks
Setup PM
Windows SDK

Setup in the Windows SDK

wsdkblog@microsoft.com — Thu, 13 Apr 2006 02:45:00 GMT

Hi, I'm Jason Sacks, the Setup Program Manager for the Windows SDK. It's my job to help make sure that you can set up and install the SDK, and that everything behaves as expected in setup.

To that end, if you're having setup problems, I'd like to refer you to two entries in my blog:
"This installation package could not be opened."
and
A summary of our installation issues

And if neither of those entries are helpful, please email me directly. It's my job to have as close to zero installation errors as possible, so if you report any issues you encounter, it will help me do my job better.

Moving into our Beta 2 release, we've done a lot of work to make setup more robust and less error-prone. We've improved our logging, implemented a number of checks to make sure up front that you have sufficient disk space and the correct version of the Windows Installer (among other problems), and that it's easier for you to select just the content that you want to install. I think we're making steady improvements towards making our setup heartier and less error-prone, and a better experience all-around for you.

Bottom line for me is that setup should be something that works quickly and easily for you. If it doesn't, or if you have suggestions for how we can do things better, please post in your comments or shoot me mail.