I installed Visual Studio 2012 and went to go publish one of our applications, that is targeted at the .NET 4.0 framework. Due to the setup on these machines, we can not target 4.5 at this time. We are also using the 'Download prerequisites from the same location as my application' feature.
When going to deploy from Visual Studio 2012, I get the following error:
To enable 'Download prerequisites from the same location as my application' in the Prerequisites dialog box, you must download file 'DotNetFX40\dotNetFx40_Full_x86_x64.exe' for item 'Microsoft .NET Framework 4 (x86 and x64)' to your local machine. For more information, see http://go.microsoft.com/fwlink/?LinkId=239883.
If you go to that link, it tells you to navigate to the Package.xml file, and find the link for the actual prerequisite. In my case, it should go to http://go.microsoft.com/fwlink/?linkid=182805. Using that link it downloaded a package named dotNetFx40_Full_setup.exe. I placed this in the /Packages/DotNetFX40
folder.
When trying to publish again from Visual Studio 2012, I got the same error. It seems that it does not like this file.
If I publish the same application to the same location with Visual Studio 2010 now, it still works just fine.
How can I get this to work with Visual Studio 2012?
I was having the same problem.
Rename the dotNetFx40_Full_setup.exe file that you download into the C:\Program Files\Microsoft SDKs\Windows\v8.0A\Bootstrapper\Packages\DotNetFX40 directory to dotNetFx40_Full_x86_x64.exe.
I was able to successfully publish my application after doing this.
Visual Studio 2012 breaks the ClickOnce installer, that's if you even got Visual Studio 2012 to update your application without telling you that it is no longer supported.
If you managed to upgrade your solution like you have, you'll find that ClickOnce actually publishes fine. It's only that the prerequisites fail to install therefore making the installation fail. If you still have a Visual Studio 2010 copy of your code that has never been touched by Visual Studio 2012 you can still build via that copy even if you update the code with Visual Studio 2012-written code via your source control. As long as that build stays untouched, it will continue to work, but if Visual Studio 2012 gets its hands on any of the ClickOnce files on that copy specifically, it will simply fail to find dependencies.
I for one decided to leverage off the fact that it still publishes and built a custom tool which can install and run any ClickOnce application as long as it can build. It can install to any location, elevate if needed, install any listed prerequisites (developer controlled), and create the desktop and start menu entries, which then run an updater that does a smart update as ClickOnce would do (only update necessary files to avoid excessive bandwidth usage). I have also built in an update source picker while in a debug environment.
This requires only that two EXE files be placed into the publish folder and you install from the third-party installer, not the ClickOnce ones. This give me a lot more functionality (I can make it do what I want, multi-threaded installer/updater, downgrade capabilities for developers to roll back) and freedom to change the updater (theming) or how the install gets done.
For those that see that my execution order is "Fake exe shortcut" ---> Updater ---> exe, you'll notice that would actually break pinning, because you'd pin the updater, not the EXE file, so I made the application run only with an argument of "/updated", if it wasn't present, the application itself must run the updater EXE file present in the same folder (which only shows if there are files to update), which then updates and starts the original EXE file again with the correct command argument. Pinning now works as you only open the EXE file. (This also gives the capability to skip an update by putting the command argument into the TargetPath, and best of all the end user knows nothing as it's a background progress and the installer is professional and branded).
I had a similar problem.
The registry key specified in the MSDN documentation http://msdn.microsoft.com/en-us/library/ms165429(v=vs.110).aspx pointed to directory c:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bootstrapper\ as the packages directory that was incorrect.
Visual Studio 2012 was looking for the packages in the C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\Bootstrapper\Packages directory. At first glance, the packages appeared to be in the packages directory, but only the package folders were there, with the executables missing from each package folder. For example the DotNetFX40Client sub directory was in the packages folder but the file dotNetFx40_Client_x86_x64.exe was missing from the DotNetFX40Client folder.
I believe you can download the correct setup program dotNetFx40_Full_x86_x64.exe from:
http://www.microsoft.com/en-us/download/details.aspx?id=17718
(rather than renaming the .NET Framework 4 installer as suggested by Brian). Place it in the
C:\Program Files\Microsoft SDKs\Windows\v8.0A\Bootstrapper\Packages\DotNetFX40
directory. I had a similar problem with the .NET Client Profile setup. In my case I was led astray to the wrong setup program by following Microsoft MSDN Help.