none
PublicKey token warning building .NET 3.5 SP1 Installer Project? RRS feed

  • Question

  •  

    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:

    Warning 1 The 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.vdproj Video File Renamer Setup

    and:

     

    Warning 2 The 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.vdproj Video 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?

    Thursday, August 14, 2008 2:47 AM

Answers

  •  

    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:

    3082010A0282010100A2DB0A8DCFC2C1499BCDAA3A34AD23596BDB6CBE2122B794C8EAAEBFC6D526C232118BBCDA5D2CFB36561E152BAE8F0DDD14A36E284C7F163F41AC8D40B146880DD98194AD9706D05744765CEAF1FC0EE27F74A333CB74E5EFE361A17E03B745FFD53E12D5B0CA5E0DD07BF2B7130DFC606A2885758CB7ADBC85E817B490BEF516B6625DED11DF3AEE215B8BAF8073C345E3958977609BE7AD77C1378D33142F13DB62C9AE1AA94F9867ADD420393071E08D6746E2C61CF40D5074412FE805246A216B49B092C4B239C742A56D5C184AAB8FD78E833E780A47D8A4B28423C3E2F27B66B14A74BD26414B9C6114604E30C882F3D00B707CEE554D77D2085576810203010001

     

    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

     

     

     

     

     

    Thursday, August 21, 2008 5:24 PM
    Moderator

All replies

  • Does anyone know how to get the correct PublicKey values?

     

    Thursday, August 14, 2008 10:02 PM
  • 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

    Monday, August 18, 2008 8:16 AM
  • 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.

    Monday, August 18, 2008 4:15 PM
  • Hi MartinPaternoster

     

    Please look at this page:

    http://download.microsoft.com/download/A/2/8/A2807F78-C861-4B66-9B31-9205C3F22252/VS2008SP1Readme.htm

    See: 2.3.1.1 Enable Samesite for the .NET Framework 3.5 SP1 bootstrapper package

    I am sorry since your problem just occurred after the VS and .Net Framework updated, Please try the solution to see if it help or you would have to contact Visual Studio product or .Net Framework product team for help. The expert there may solve such kind of problem.

     

    Best Regards,

    Kira Qian

     

    Windows Forms General FAQs
    Windows Forms Data Controls and Databinding FAQs

     

    Tuesday, August 19, 2008 3:53 AM
  • 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.

    Tuesday, August 19, 2008 5:12 AM
  • I'm getting the exact same warning messages after following the readme steps.

     

    Tuesday, August 19, 2008 2:34 PM
  • 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?

    Thursday, August 21, 2008 9:21 AM
  •  

    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

    Thursday, August 21, 2008 2:51 PM
  • 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.

     

    Thursday, August 21, 2008 3:22 PM
  •  

    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:

    3082010A0282010100A2DB0A8DCFC2C1499BCDAA3A34AD23596BDB6CBE2122B794C8EAAEBFC6D526C232118BBCDA5D2CFB36561E152BAE8F0DDD14A36E284C7F163F41AC8D40B146880DD98194AD9706D05744765CEAF1FC0EE27F74A333CB74E5EFE361A17E03B745FFD53E12D5B0CA5E0DD07BF2B7130DFC606A2885758CB7ADBC85E817B490BEF516B6625DED11DF3AEE215B8BAF8073C345E3958977609BE7AD77C1378D33142F13DB62C9AE1AA94F9867ADD420393071E08D6746E2C61CF40D5074412FE805246A216B49B092C4B239C742A56D5C184AAB8FD78E833E780A47D8A4B28423C3E2F27B66B14A74BD26414B9C6114604E30C882F3D00B707CEE554D77D2085576810203010001

     

    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

     

     

     

     

     

    Thursday, August 21, 2008 5:24 PM
    Moderator
  •  

    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

     

    Monday, August 25, 2008 5:10 PM
    Moderator
  • I noticed this issue investigating SP1 and 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 upon the lack of SQL Server 2008 and Windows Installer 4.5 prerequisite packages in VS 2008 SP1, the two are missing because of a choice to not provide it by default in 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

     

     

    Thursday, September 11, 2008 10:35 AM
  • 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!

     

    Friday, September 12, 2008 4:21 AM
    Moderator
  • Yes, in the default scenario there is no need to correct the Product/Package.XML files.

    Issues (minor and major) with ClickOnce usually affect 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.

     

    Friday, September 12, 2008 7:22 AM
  • 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?

    Thursday, September 25, 2008 2:18 PM
  • 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.

     

     

    Tuesday, November 25, 2008 7:24 PM
    Moderator
  • Where is the Product.XML file located?  I don't know how to find it.  thanks.
    Adam Kane, Technical Director, ForgeFX, http://www.forgefx.com/
    Monday, October 5, 2009 7:47 AM
  • This is completely silly that I need to hop through all these hoops just to get the clickonce ____ to work...
    Tuesday, November 3, 2009 6:23 PM
  • I created a bootsrapper for sql express advanced edition 2005 by customizing and modifying the sql express bootstrapper.

    I, of course had the same stupid problem with the public-key.

    I used the manifest generator to get the public key and put it in my bottstrap package,  that did not solve the problem
    I am still getting the warning !!!

    Obviously this same problem still exists in vs 2008 :)

    and using the manifest generator did not solve the problem

    Tuesday, December 15, 2009 12:27 AM
  • I just wanted to mention that I got these two errors today with the Setup project type in Visual Studio 2010 RC.  I hope this doesn't slip past QA (again) in the final release. :)

    Thanks,
    Eric
    Sunday, February 28, 2010 2:37 PM