So glad this came back. The only problem I found is that my msi wouldn't run on POSReady 2009 and Windows XP but I resolved this by following the advice from http://stackoverflow.com/questions/23978677/dirca-checkfx-return-value-3-vs-2013-deployment-project
Great to have this back. I finally could upgrade to VS2013 (we use setup projects a lot and are using it to create .msm files which is not supported by the Installshield included). We found one problem with it though: if we add the Project Output from an SQL CLR project Visual Studio seems to crash when building the setup.
For the people who are complaining that VS 2013 is crashing, do you by any chance have "Web Essentials" add on installed? I found out that these two extensions don't play well together. Disabling the "Web Essentials" add on fixes the crash on open issue for me.
I imported into Visual Studio 2013 a Setup and Deployment project created in Visual Studio 2010. In my project, I had selected 'Download prerequisites from the same location as my application. But when I tried to build my setup project, I was getting an error such as :
To enable 'Download prerequisites from the same location as my application' in the Prerequisites dialog box, you must download file 'XXXXXXXX' for item 'XXXXXXX' to your local machine. For more information, see http://go.microsoft.com/fwlink/?LinkId=239883
In this case, the link was actually useful for solving the problem. Basically I had to download the MSIs and then copy them to the Bootstrapper folder where it checks--in my case: C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\Bootstrapper\Packages\<folder for prerequisite>\
When I was using Visual Studio 2010 I didn't have to do this--the redistributable MSIs were already in the correct bootstrapper folder.
Maybe the Visual Studio Installer Projects Extension should add them as part of the install to avoid this hastle for others
Although the Productcode is different, RemovePreviousVersions is true, Version is higher, file versions of DLLs are higher an upgrade installation seems to run through without any errors (in UI). But if you look in the installation folder then only a new DLL is placed there, all the others that should have been replaced are deleted. Registry settings are fine. A new installation is also fine. Has someone similar experiences? The setup properties are the same as in the installer we build with VS2008. There the upgrade installation worked.
This is also happening with our software. RemocvePreviousVersions=true installation executes OK with no errors.
1. the uninstall of the older product’s files runs OK
2. COM deregister of older product fails
3. Deployment of all files from the new setup package fails
4. COM registration of new product is OK (although points to a non-existent file and is a duplicate)
Setting RemoveProviousVersions=false completes the install OK - old files are overwritten and our software runs OK. Both old and new versions are displayed in "Programs and Features" list - as you'd expect I suppose.
Has anybody come up with a workaround?
This extension is not working with my copy of Visual Studio 2013.. I believe it is because it is not installed in the default "C:\" hard drive on Windows 7 x64...
Does anyone know a workaround to using this extension with Visual Studio 2013 installed on a different hard drive (other than the primary one)?
Is there a reason that the GUIDs are being regenerated each time the installer project is saved? It makes it almost impossible to see what was changed by doing a diff. It would make it so much easier if the GUIDs would stay the same. I realize that some GUIDs need to change. I'm more referring to the internal GUIDs that stitch the installer together.
I'm still getting the error "An error occurred while validating. HRESULT = '8000000A'" when running from command line. I have set HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0_Config\MSBuild\EnableOutOfProcBuild to 0.
Using version 184.108.40.206 with VS 2013 update 4.
Any new version coming soon?
I've indeed the same problem with my TFS automated builds.
I try to launch the msi generation by using all the steps described in the following post (http://geekswithblogs.net/jakob/archive/2010/05/14/building-visual-studio-setup-projects-with-tfs-2010-team-build.aspx) but it doesn't work.
My build server currently runs with TFS 2013 and a VS 2013 version having this plugin but it doesn't work.
I have set the HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0_Config\MSBuild\EnableOutOfProcBuild registry value to 0 but it works only if i launch the msi generation through Visual Studio 2013...
It is really a shame that Microsoft doesn't fix this issue when i see that we are a lot to wait for a VALUABLE fix !!!
We were so happy to see a REAL installer back in VS2013, InstallSheild LE is terrible and so crippled its near useless.
I have a simple website to deploy thats built using our build server from the command line - we constantly get the following error.
------ Starting pre-build validation for project 'HelpDeskVSInstaller'
------ ERROR: An error occurred while validating. HRESULT = '8000000A'
------ Pre-build validation for project 'HelpDeskVSInstaller' completed
I have been able to replicate this on my local box by running the installer from the command line:
C:\Windows\system32\cmd.exe /s /c ""C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\devenv" "Payzone.Web.sln" /Rebuild Release /Project VSInstaller"
The installer is able to be built from inside VS2013 IDE. Can you let me know how I can fix this issue?
We have the same error while building from command line. The installer builds OK from GUI.
http://stackoverflow.com/questions/8648428/an-error-occurred-while-validating-hresult-8000000a has an explanation for older Visual Studio versions. I wonder if the problem was addressed in VS 2013 and this extension.
It seems that there is more than 1 person with this issue - Is anyone from Microsoft care to comment on this on how to get around it.
We need to build from the command line and the gui is not an option for us. The installer should work from the command line.
I have removed all the extra lines in the build as per the question / answer on stack overflow referenced by Aurimas above.
This is still not working from the command line.
PLEASE PLEASE PLEASE PLEASE get back to us on a how to fix or if its not going to be fixed so we can start using an installer that does what it says on the tin!!
Same problem here, it's very frustrating and now we can't script Builds from our Build server and therefore will still need to find another way to Build the product. Works fantastically from the UI though, but not really practical to deliver it this way and to be honest it should work the same as in the UI
BUMP BUMP -
Cmon guys someone must be aware of this and have a fix or workaround? I cannot believe that there hasnt even been a response to this from VS Team......
We are basically not going to use Microsoft installers for any future projects because of the current shambles of the recent releases.....
As an update - I did try the workaround posted on the main page with v220.127.116.11 release - and this fixes issues when executing from the command line for the current logged in account - but invoking the same command line parameters from our build process still fails with the HRESULT = '8000000A' error on the same server. Does the registry key have to be added elsewhere when running as a TFS service account?
Anyone know if this extension is able to transform web.config files for a Web Application (release, debug, etc) the way Studio does with the "Publish" option?
Been using Wix til now which works ok but is high maintenance.
I am trying to add application shortcuts in the "File System Editor" like in VS 2010, but it is not possible.
I only have the option to create a shortcut to, for example, the 'Application Folder'.
I have also tried to use the Add --> Project Output context menu, but the output is not added. It just messes up the Deployment Project File, so I have to open it in Notepad and remove the entries again manually.
Is this a known issue? Have anyone else experienced this issue? Does anyone have a solution or workaround for it?
Launch Conditions for .Net 4.5 and above only checks for the "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full" registry, instead of checking the value of the Release DWORD.
To confirm this I have created an installer with a launch condition of .Net 4.5.2 and ran it successfully on a clean Windows Server 2012 R2 machine without issue (4.5.1 is standard on Server 2012 R2). When trying to run the installed software, it crashed as 4.5.2 was not present on the target machine.
I have also confirmed this on a 2008 R2 machine with .Net 4.0 installed – the launch condition was successful in recognising that the "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full" registry was missing, but after installing .Net 4.5 (2 versions below the required 4.5.2) which created the "Full" subkey, the launch condition message was not shown and the installer ran.
The information on the MS page https://msdn.microsoft.com/en-us/library/hh925568(v=vs.110).aspx describes the values of the Release DWORD that correspond to the versions of the .Net Framework, and it would seem that this is not being checked at present.
Yesterday I installed KB 2829760 which fixes the the problem with Update 4.
I am now able to import .vdproj files into my solution and I have successfully produced a new installer package.
So it would seem this Visual Studio Installer Projects extension is now working again.