I'm new to MSI's. I've created a Window's Service that is the output project for my MSI. My local machine is a 64-bit Win 7 machine. The server I am trying to install on is a Win 2008 32-bit server running on a VM. I'm using .NET 4 VS2010.
Currently, my service's exe is building as a release target = Any CPU in the Config Manager. The MSI, does not give me any option to change the platform.
I can install no problem on my local 64-bit Win7 machine. However, whenever I try to install on the 32-bit Win 2008 I get the following error:
"This installation package is not supported by this processor type error. Contact your product vendor."
I tried changing the service's target to x86 rebuilding the exe and the setup, but I get the same result. The service references a number of class libraries. I changed those from Any Cpu to x86 as well just to see if that made any difference.
I also, made sure that my Setup project and Service Prerequisites are set to .NET Framework 4 (x86 and x64). I also experimented with changing the Prerequisites Windows Installer from 3.1 to 4.5.
Nothing seems to work. Any ideas? Thanks.
In my case, having entries specified under the HKLM/SOFTWARE (64-Bit) registry node was enough to cause installation failure on a 32bit Win7 host.
The symptoms were the same for VS 2010/2013 using the free, integrated InstallShield product. I was able to keep the Any CPU settings on the project being installed. There were no other special settings required for the MSI setup project.
OK, I figured out where the TargetPlatform is. It is different than on other VS Projects.
To access the TargetPlatform, select the MSI project and press the F4 key. Viola! Within the "Properties" grid, you will find the TargetPlatform field with options: x86, x64, Itanium. NOTE: this is a completely different set of properties that you get when you Right-Click on a project and select the "Properties (Alt-Enter)" item from the context menu. "Alt-Enter" Properties vs "F4" Properties.
Unfortunately, this is different than the other VS Project properties. Typically, Project Properties are set in the Main Window, not here in the "F4" properties grid. Hence, I kept getting confused when other threads discussed the properties of the project since this is different.
such as this one
ConfigurationManager in VS does not affect the MSI. I'm keeping all my dependent assemblies on "Any CPU". Also, don't forget target the correct framework in the "Launch Conditions" Window (right-click project -> View -> TargetConditions).
Hope this helps.
I am kind of late to answer this question! F4 does not work on Visual Studio 2017. Just highlight the Setup project, then right-click on Properties-tab on the RIGHT side-bar. Then change the "TargetPlatform" to your desired option. Please, note: This is different from right-clicking on the Setup project.
Related
I need to build a vdproj on a jenkins machine (Windows Server 2012 R2)- which requires devenv.exe and not msbuild. I cannot install Visual Studio.
Devenv.exe is required for a MSI package.
I've used process monitor and determined I require one more file for devenv.exe to work : api-ms-win-core-heap-l2-1-0.dll
This file does not exist on any developer machine that we have, and devenv.exe/devenv.com works on the dev machines.
Where can I find this file?
Are there other ways to build a vdproj without Visual Studio?
Virtual Machine: This sounds a little hairy I am afraid. Could you use a virtual machine - with Visual Studio on it - to build the Visual Studio Installer project in question?
WiX et al: Converting to WiX or another deployment tool besides Visual Studio Installer Projects would solve the problem? Is this a very complicated installer? Using the WiX decompiler dark.exe to decompile an MSI to WiX markup can help you convert the installer to WiX format. Quite a bit of WiX knowledge will be required to do this successfully. Maybe something a consultant could do quickly? Depends on the complexity.
Windows API-set: As far as I know api-ms-win-core-heap-l2-1-0.dll is a Windows API-set, and not a real file or real dependency as such. These are new constructs in Windows. Try opening such an API-set file with Dependency Walker to see what they redirect to. Pretty mysterious these API-sets:
An API Set is a strong name for a list of Win32 APIs. The convention
for assigning a strong name to an API Set is to use what appears to be
a dll name. But the purpose of an API Set is to provide architectural
separation between the API Set's name and its associated host DLL
implementation for improved portability of your app, so you should
think of an API Set's name as just a unique character string, and not
as a dll name. For delay load, you use the name of the API Set.
API Sets rely on operating system support in the library loader to
effectively introduce a namespace redirection component into the
library binding process. Subject to various inputs, including the API
Set name and the binding (import) context, the library loader performs
a runtime redirection of the reference to a target host binary that
houses the appropriate implementation of the API Set.
The decoupling between implementation and interface contracts provided
by API Sets offers many engineering advantages, but can also
potentially reduce the number of DLLs loaded in a process.
On disk I find most of these API-Sets in %SystemRoot%\WinSxS and %SystemRoot%\System32\downlevel.
Nice article on the technical aspects of this new API-Set feature.
Complex Executable: Though devenv.exe is just an EXE file like any other, I do think there will be dependencies for Visual Studio Installer Projects beyond just dll import tables that will be very hard to set up properly, and what about future releases when all can fail without warning? (if something changes - Visual Studio has been a pretty moving target of late).
WiX Quick Start: Here are some of the best links that I have found over time for WiX:
Some WiX Quick Start Tips - chaotic, but
upvoted. Must have been helpful.
Helge Klein's real-world WiX sample - do check this out.
Rainer Stropek's WiX Samples on Github - can be very helpful.
From MSI to WiX by Alex Schevchuk - aging content, but excellent.
I downloaded and installed the Delphi 10 trial. However, every time I try to build anything at all, I get this: MSBuildToolsPath is not specified for the ToolsVersion "12.0" defined at "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\12.0", or the value specified evaluated to the empty string
The 12.0 key does not exist within "ToolsVersions" on my pc. I do however have 2.0, 3.5, 4.0 and 14.0. I also have a full, perfectly-working installation of Visual Studio 2015 Community, if that knowledge helps. I am running Windows 10 Pro, 64-Bit. What can I do to correct this issue? It's the first time I've ever had a problem with any version of Delphi/RAD Studio... was actually not aware the Rad Studio IDE cared about or used or had anything to do with MSBuild until now.
It is a known issue, documented here:
https://community.embarcadero.com/article/technical-articles/16202-msbuildtoolspath-is-not-specified-for-the-toolsversion
This error is caused by incorrect values in the registry. On a 32 OS, run regedit and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild. On a 64 bit OS, run regedit and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSBuild. First, backup this registry key by selecting File | Export. Next, look at the numbers below the ToolsVersions key. Delete any number not found at the MSBuild level.
...
There is anecdotal evidence to suggest this registry key imbalance is caused by uninstalling some versions of Visual Studio, but it has not been confirmed at this time.
Since I've been installing/uninstalling various Visual Studio versions (including previews), guess it has indeed been caused by that
Error "A default tools version "2.0" was specified, but its definition could not be found." may appear then if you deleted the 2.0 key following the 1st article's advice. Solution for that one is to edit each value under MSBuild key in the registry locations mentioned for x32 and x64 and change DefaultToolsVersion to 14.0 or other highest MSBuild tools version that is installed
Note that on x64 machine you need to fix these two issues for both x32 and x64 registry locations, since the IDE is 32-bit process and if you fix x64 location only it will fail internally, underlining all Standard units at uses clause in your source code and showing “Cannot resolve unit name xx”
Also it may be useful to install this:
https://www.microsoft.com/en-us/download/confirmation.aspx?id=48159
This may also be useful to know (copying from https://msdn.microsoft.com/en-us/library/bb383985.aspx):
Order of Precedence
The order of precedence, from highest to lowest, used to determine the ToolsVersion is:
The ToolsVersion attribute on the MSBuild task used to build the project, if any.
The /toolsversion (or /tv) switch that's used in the msbuild.exe command, if any.
If the environment variable MSBUILDTREATALLTOOLSVERSIONSASCURRENT is set, then use the current ToolsVersion.
If the environment variable MSBUILDTREATHIGHERTOOLSVERSIONASCURRENT is set and the ToolsVersion defined in the project file is greater than the current ToolsVersion, use the current ToolsVersion.
If the environment variable MSBUILDLEGACYDEFAULTTOOLSVERSION is set, or if ToolsVersion is not set, then the following steps are used:
The ToolsVersion attribute of the Project element of the project file. If this attribute doesn’t exist, it is assumed to be the current version.
The default tools version in the MSBuild.exe.config file.
The default tools version in the registry. For more information, see Standard and Custom Toolset Configurations.
If the environment variable MSBUILDLEGACYDEFAULTTOOLSVERSION is not set, then the following steps are used:
If the environment variable MSBUILDDEFAULTTOOLSVERSION is set to a ToolsVersion that exists, use it.
If DefaultOverrideToolsVersion is set in MSBuild.exe.config, use it.
If DefaultOverrideToolsVersion is set in the registry, use it.
Otherwise, use the current ToolsVersion.
I resolve my problem in delphi that need the Msbuild 14, i just download and install the msbuild that match my error message, in my case:
https://www.microsoft.com/en-us/download/details.aspx?id=48159
i think that you could download the msbuild from microsoft site to see if it works.
I wrote a windows service that runs on Framework 4.0 and running in VS 2015.
I also created a setup project (free Installshield version).
My service did not show under services.msc after I installed it, so according to some other posts I had to mark the Primary Output in InstallShield as 'Installer Class', but when I do that I get Error 1001 when I run the setup.exe.
This post states that "Error code 1001 ALWAYS means a failure in the Installer class custom action." and that I should not use Custom Actions. I'm not using any custom actions at the moment.
Most of the solution on this site have instructions for Installshield 2010, and the steps does not work for 2015.
The error appears on both my dev machine as well as all client machines.
Any suggestions?
EDIT:
The event viewer displays "Failed to create restore point (Process = C:\Windows\system32\msiexec.exe /V; Description = Installed My App Name.; Error = 0x80070422).
I had this exact same issue. Suddenly after upgrading to VisualStudio 2013 and the newer InstallShield LE and building my installation packages they would fail with the cryptic 1001 error.
Definitive Answer
I found the definitive answer. You can no longer have the checkbox for "installer class" selected in InstallShieldLE. You must uncheck that item.
In order to open this dialog box, go to Specify Application Data > Files and right click on your Primary Output and select Properties.
Previously, You Had To Have It Selected: Now It Must Not Be Selected
Previously (Visual Studio 2012 and before you had to have that item selected or the service installation would fail. This is quite terrible.
Now, you have to go to following tree item in the InstallShield LE project and double-click the Services node:
After that the Services item appears on the left (have I mentioned what a terrible UX and UI this entire thing is?) and right click it so you can add the service.
Choose the menu item which appears to add the service and you'll get a form which allows you to set up the installer details.
Once you do that and rebuild your MSI will work and this will resolve the 1001 error.
This was all a terrible waste of time that the original InstallShield Devs could've resolved. Unfortunate.
If you have .NET 4.6 installed on your build machine, you'll need the 2015 version of the limited edition to avoid a versioning bug with InstallShield's support for Installer Classes. (There are many causes for a 1001 error, so this is not a guaranteed fix.) Note that InstallShield 2015 Limited Edition does not support the community edition of Visual Studio.
Hopefully this will help some of you encountering the Error 1001 when trying to install a .NET Windows Service using InstallShield 2015 LE installer project with the Primary Output set as an Installer.
It's a known bug when .NET 4.6 is installed on Windows 10.
https://flexeracommunity.force.com/customer/articles/en_US/ISSUE/HOTFIX-Install-Fails-With-Error-1001-When-a-NET-Installer-Class-Component-is-Present-in-InstallShield-2015-SP1
Since i cant comment yet i will just reply with an answer to your own accepted answer. I know it has been a while since you asked the question but here goes.
If you want auto start after install you can go to step 3. Configure the Target System. Choose the Services tab. Right click Services and add Service. You should be able to locate any service in your Primary Output. Once added you can select different settings related to auto start and so on. Hope it helps you.
On a side note, i am still looking for the answer to my 1001.
This error occurs when targeted .NET framework is not installed.
If you are targeting the same development machine then please check if that service (EXE) is already running on that machine or not (It should not running).
I found something to get rid of the problem, but it does create a new question, albeit a much simpler and less critical one.
What caused my problem is that I had to remove the following code from my ServiceInstaller's AfterInstall:
new ServiceController(ServiceInstaller.ServiceName).Start();
This was added to auto start my service once it has been installed. For now I will just manually start the service.
I am using VS 2012 with InstallShield LE 2015 targeting .NET 4.5 and I have to uncheck the "Installer class" for it to work.
After some digging I found out that the installer fails with that error when it tries to remove the service (associated with whatever you are installing) - AND (the service) is not there anymore.
My use case scenario - Start install from MVS2015 of a complex solution that comprises also a windows service.
When you change the version of the solution, the installer stops in its tracks finding that the your app was installed before and can not uninstall it as it is a different version. It pops up a dialog box stating this and exits .... BUT IT HAS UNINSTALLED the service.
Now trying to install or uninstall fails with the error 1001 because windows doesn't find the service to uninstall it.
If somebody has a better solution please post it, but my solution is to use sc command line utility. sc is a utility that can be used to manipulate services from the command line (type sc for help). So i use sc to add the service (by name), and then I can do uninstall, or install as usual. Is compulsory to have a valid bin path in command - but ANY valid path will be accepted.
sc <server> create [service name] [binPath= ] <option1> <option2>...
Example:
sc create MyService binPath= C:\Windows\explorer.exe
[SC] CreateService SUCCESS
I'm trying to make an ActiveX control for an application on a Windows CE 6.0 device, but I can't get it to register on the device. When I transfer the .ocx file over to the device and try to register it using regsvrce.exe, it fails with error 7e, which I've learned means a dependency is missing. How can I identify which dependency is missing? Alternatively, have I gone about creating the ActiveX control wrongly?
I have loaded the .ocx in Dependency Walker on my development machine (running Windows 7 64-bit, if that matters) and all of the top-level dependencies it lists are present on the CE device. I can't check further down the tree since Depends then looks for the top-level dependencies on my development machine, half of which are missing since they're CE-specific. Dependency Walker doesn't run on the CE device (unless there's a CE version I've missed?). I tried to copy the DLLs from the CE device to a flash drive so I could load them into DW on my development machine, but the device won't allow me to do so. The OEM tool I have for transferring files unfortunately only transfers to the device. [Edit: I haven't tried writing my own tool to try to pull files from the device to development machine.]
Some details on how I've set up the project, in case I have some wrong assumptions on that end. I have tried with two projects. One has my code in it (the ActiveX Control itself is just a graphical representation of some data, which I had originally set up in a win32 ActiveX control to see how it looks), and one is a clean project - created from template, compiled, downloaded to device; no code added or configuration changed. Both have the same result when trying to register.
Using VS2005, created a project using the "MFC Smart Device ActiveX Control" template, targeting the SDK I received from the OEM.
In the case of the project with my code in it, I copied my drawing code into the project and created the necessary properties for the data input. I can provide more details on my code if it would help, but my issue happens even without the code. I am assuming that since it compiles successfully when targeting the SDK from the OEM that the functions I am using are supposed to be available on the target device.
Build the project in Release configuration (I wondered if the debug libraries were missing on the target device and causing the issue).
Transfer the .ocx file to the target device using an OEM tool.
Start command line on target device, move to directory the .ocx is in, run "regsvrce.exe .ocx". I have also tried transferring all of the files that VS leaves in the build output folder, but the result is the same.
Many thanks in advance for any answers! If you see something obvious point it out - this is my first ActiveX project and my first CE project, so it's very possible I'm missing something basic.
Since you build OCX I assume that you are using MFC. How do you link with MFC? Look in project settings|General, try to select "Use MFC in a Static Library". Same goes for ATL - try selecting "Static Link to ATL" (if you use ATL). This goes also for VCRT - in C/C++|Code Generation, in "Runtime Library" try selecting options without the 'DLL' (i.e. - statically link with VCRT).
Since the default empty OCX does not work for you - this is the only thing I can think of...
Another thing - I assume you have a reason for working with Visaul Studio 2005? Why not a newer version?
Good luck, PazO
I have a user that is trying to access a team project that he has been working with (in).
He has 2 computers, on 1 he can access it, on the other he can't (project has red x). And actually he can access any projects on that machine, all have the same red X.
He was been able to accesses the project on both machines last week. And I have no idea what could have changed.
Searching the web found a # of post regarding folder within a project with a red X but not much on a project itself. But we tried these 2 links ...did not help
visualstudiomagazine
social.msdn.microsoft
Also tried re-installing Team Explorer & installed SP 1 (it was not on the machine).
Any ideas where to start looking?
Thanks
The 'Red X' problem can be from many different causes.
However, seeing as the user is experiencing the problem on one machine, and not on the other means that it's unlikely to be a server-side issue.
On the computer that is having the problem:
Close all instances of Visual Studio
Close any other applications that could be using the TFS Object Model
Open and delete the contents of the following folder: %localappdata%\microsoft\Team Foundation. On Win7, this will typically expand to something like C:\Users\<username>\AppData\Local\Microsoft\Team Foundation
Start Visual Studio again and connect to TFS
TFS clients have a local cache of metadata. There are situations where this metadata can get corrupted. Therefore, deleting it will force a fresh download of the metadata and resolve the Red X issue.
Enabling tracing on the client and/or TFS server should allow you to track down the error.
This happened to me after installing .NET 1.1, Visual Studio 2003, Active Reports 2.0 and Dundas Charts on 64-bit Win 7. None of the other fixes worked for me, but I resolved my issues (which also included weird IE behavior) after running the ie8-rereg.32-on-64.cmd script found here: http://iefaq.info/index.php?action=artikel&cat=42&id=133&artlang=en.