I just upgraded to VS 2008 SP1, and .NET 3.5 SP1.

After extracting the appropriate .NET 3.5 SP1 archive and altering the product.xml (per Readme), then building the Installer, I het 2 warnings:

Warning1The value of the 'PublicKey' attribute in '.NET Framework 3.5 SP1' does not match that of file 'C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages\DotNetFX35SP1\dotNetFX30\XPSEPSC-x86-en-US.exe'.C:\Users\OneBuckFilms\Documents\Visual Studio 2008\Projects\Video File Renamer\Video File Renamer Setup\Video File Renamer Setup.vdprojVideo File Renamer Setup

and:

Warning2The value of the 'PublicKey' attribute in '.NET Framework 3.5 SP1' does not match that of file 'C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages\DotNetFX35SP1\dotNetFX30\XPSEPSC-amd64-en-US.exe'.C:\Users\OneBuckFilms\Documents\Visual Studio 2008\Projects\Video File Renamer\Video File Renamer Setup\Video File Renamer Setup.vdprojVideo File Renamer Setup

I'd love to know why this is the case, and if Microsoft could provide the correct PublicKey token values for the product.xml file?

Hello All,

Let me shed some light on this issue.

We are still investigating why the Public Key Tokens of the actual files are different than what we have in the product.xml files. Needless to say, something slipped by despite our testing. You have my apologies for that.

The good news is that the bootstrapper works quite well in this situation. When we build, we compare the digital signature of the file on disk to the PublicKeyToken listed in the product.xml or package.xml. If they are different, then we use the value of the actual file on disk, since this is what will be copied and/or posted in a "Same Location as my Application" scenario. This way, the bootstrapper works correctly.

We do show a build warning, to alert the developer / builder that something is different than was expected. This has value in the "Download from the Component Vendor's Web Site" scenario because if the file being downloaded from the Component vendor is the same as is on disk, then the download will fail the certificate test and won't install. Fortunately, in this case, in that scenario only the dotnetfx35setup.exe file is actually downloaded from Microsoft, and that key is correct.

If you wish to get rid of the build warnings, you can update your PublicKey in the Product.XML with the following value:

Use this for both of the XPSEPSC* files.

I hope this helps to clarify things, and we are going to continue to follow-up. Thank you for reporting this, it will help us keep more people from running into this.

Sincerely,

David Guyer

Program Manager - Setup Projects

Visual Studio

Hi MartinPaternoster

I want to know that why did you attempted to do by modifying product.xml, which package did you use and where did you download from.

Please give me more detail information before I can go on to locate the problem.

Best Regard

Kira Qian

I downloaded .NET Framework 3.5 SP1 Full Archive, as per the Visual Studio 2008 SP1 Readme File.

This was so that the .NET Framework would be installed from the same location as my EXE.

Aside from the added 4 entries from the Readme, there were no other modifications to the product.xml.

This is the section of the Readme I followed. I followed this section exactly, although I had to find the .NET 3.5 SP1 full download on Microsoft.com, since the link provided failed.

Also getting the same problem (see thread http://forums.msdn.microsoft.com/en-US/vssetup/thread/d3c1991a-9353-43f0-be82-2dacedc1ceba/).

Why is there this discrepancy? Is this anything to be concerned about?

I got the same problem, after having followed the same procedure.

I must say that I'm not very happy to build my product and deliver it to my customers with components supposed certified by Microsoft, but with signature error. It's pure non-sense. Either we use signatures, public keys, etc and we have to trust them, or we stop using them if we cannot trust them.

Luc

Ladies and Gentlemen, welcome to the "ooops" show :-)

I'll not be using the .NET 3.5 SP1 features until I can rely on the distribution mechanism.

Hello All,

Let me shed some light on this issue.

We are still investigating why the Public Key Tokens of the actual files are different than what we have in the product.xml files. Needless to say, something slipped by despite our testing. You have my apologies for that.

The good news is that the bootstrapper works quite well in this situation. When we build, we compare the digital signature of the file on disk to the PublicKeyToken listed in the product.xml or package.xml. If they are different, then we use the value of the actual file on disk, since this is what will be copied and/or posted in a "Same Location as my Application" scenario. This way, the bootstrapper works correctly.

We do show a build warning, to alert the developer / builder that something is different than was expected. This has value in the "Download from the Component Vendor's Web Site" scenario because if the file being downloaded from the Component vendor is the same as is on disk, then the download will fail the certificate test and won't install. Fortunately, in this case, in that scenario only the dotnetfx35setup.exe file is actually downloaded from Microsoft, and that key is correct.

If you wish to get rid of the build warnings, you can update your PublicKey in the Product.XML with the following value:

Use this for both of the XPSEPSC* files.

I hope this helps to clarify things, and we are going to continue to follow-up. Thank you for reporting this, it will help us keep more people from running into this.

Sincerely,

David Guyer

Program Manager - Setup Projects

Visual Studio

Another update... the online Readme has been updated to reflect updating the Product.XML with these new certificate keys, and the link to DotNetFx.exe has been fixed so everyone will download and extract the correct file.

Thank you all for your patience and discussion on this topic, and I apologize for the inconveniences this has caused. I think we've got it all straightened out.

I'd welcome feedback on the working process... is HomeSite (Component Vendor's Website) functionality in the box OK as long as you can put the files on disk (without updating the Product.XML, that's something I don't want to have to include in a readme ever again)?

David Guyer

Program Manager - Setup Projects

Visual Studio

I noticed thisissue investigating SP1and I have been surprised by this double "bug", as it is an error in the instructions on how to deal with a known issue.

I stumbled uponthe lack of SQL Server 2008 and Windows Installer 4.5prerequisite packages in VS 2008 SP1, the two are missing because of a choice to not provide it by defaultin VS 2008 SP1. While I agree that a home-made solution is available, I'm still puzzled on the reason why MSFT does not provide a SP1 refresh or a "fix" to face these issues.

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3735631&SiteID=1

So, it's a series of steps, all reasonable when understood in context. I'm fairly embarassed by the mistakes in the Known Issues, we've rarely made mistakes like that.

There was a conscious decision to release 3.5 SP1 Bootstrapper package to be Homesite Only. When used in this mode, there is no need to update the Product/Package.XML files.

There were changes is the layout and signatures of files in the 3.5 SP1 package in the last few builds. They do not affect the Homesite Only experience. Unfortunately, there were a couple things that combined to happen to cause our QA team to miss these changes when we were testing the Known Issues. It's definately unfortunate, and I apologize for the inconvenience here. We did turn around an update to Known Issues in 1-2 days, and I appreciate the heads up from this forum so that we can keep others from running into it.

The SQL Server 2008 and Windows Installer 4.5 are provided with Express SKUs.Honestly, I don't understand why they weren't included in the SP for non Express SKUs. Give me a few days, and I might be able to post these so people don't need to download Express to get them.

I hope that helps!

Yes, in the default scenario there is no need to correct the Product/Package.XML files.

Issues (minor and major) with ClickOnce usuallyaffect the same developers/companies while issues on other VS features can affect different users over time. It never rains, it pours on ClickOnce users. :-)

It would be great to have those prerequisites provided in any form by Microsoft.

I got the same Message but for the

....\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages\DotNetFX35SP1\de\DotNetFX35\x86\dotnetfx35langpack_x86de.exe

Which PublicKey i shall i copy in?

Actually, you don't really need to update the PublicKey in the XML. The reason is that we always use the value of the file on disk, instead of what's in the XML... so it's just a warning.

If you want to get rid of the warning, then the easiest way is to edit the de\package.xml file, and remove the PublicKey attribute altogether. If you really want to have the PublicKey attribute, and have no warning, download Bootstrapper Manifest Generator, and create a dummy project, load the langpack .exe file as an installer file, and check the properties, the PublicKey will be displayed on the Security Tab page.