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
Related
Previously, a few weeks back,
I asked a similar question regarding D6 and Windows 7.
After installing Delphi 6 in another path, it worked.
BUT now,
after upgrading from W7 to Windows 10 it no longer works.
I am prompted to register the software.
I do that, and am told the registration was successful.
Attempting to start again I am told license information
is invalid or missing.
The program will not start.
What is needed to run D6 in a Windows 10 machine?
There is an Howto I've found at ViaSoftThink I've translated it for you
How to:
Don’t install under C:\Programme (x86) use another folder e.g. C:\software_old
After the installation you're forced to register. Whether the registration process was canceled or successful you probably get an error message:
"License information is invalid or missing Please register"
Now do the following:
Execute c:\software_old\Borland\Delphi6\bin\D6RegClean.exe
After this install Delphi 6 from your CD but this time choose "repair"
To use the Help System you need to install WinHlp32.exe Microsoft doesn’t give you an Installation Package but you can download it here
If you follow the steps above and still have a registration error pop up there might be that you need to edit the registry at:
HKEY_CURRENT_USER\SOFTWARE\Borland\Delphi\6.0
On the right side you'll find an entry which is called LM
Delete that key and try again registering...
Please note: Messing around with the registry can break your system only do it if you know what your doing
Deletion of LM key, worked for me,
Delete key.
Reboot.
Launch Delphi, choose register later, quit.
Launch Delphi again, works OK.
Also, I modified authorization of c:/programmes/borland/delphi/bin to total control and delphi32.exe compatibility properties to Windows XP and executed as administrator.
Restart Delphi and choose register later.
New LM key will be created and you can continue unregistered
Needed to fix legacy code from 2005
My company owns several business licenses for Xamarin.Android, and we'd like to use this on our CI server. However, it seems that I'd need to install the full Xamarin suite on my CI server including Visual Studio Pro to make this work. My question is, using the vanilla Xamarin.Android package, how can I activate it?
It seems that installing this on its own adds the Xamarin.Android tools and libraries to build with but there is no way to activate it that I can find, so when I attempt to build using MSBuild, the build fails with this error:
C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(299,2): error XA9008: Building from the command-line requires aÿBusinessÿLicense.
Now, after some googling, I have found that the activation tool is called "mandroid.exe", which can be found in C:\Program Files (x86)\MSBuild\Xamarin\Android - although I have found references to this being in the 64-bit program files too.
Unfortunately, I can't find any suitable documentation on this tool. Every time I find a thread where someone discusses this, someone from Xamarin jumps in and says "contact support#xamarin.com". After a while I did that but two business days later there still is no response and I've got deadlines to meet so I thought it might be helpful for everyone involved for us to publicly document this process.
The best thing I've found comes from a thread on the Xamarin mailing list which references this invocation:
mandroid.exe --activate --name "NAME" --company "COMPANY" --email "EMAIL" --phone "PHONE" --code "ACTIVATION CODE"
I have also discovered another variant of this invocation that looks like this:
.\mandroid.exe –activate –activation-name="NAME" –activation-phone="PHONE" –activation-company="COMPANY" –activation-code="CODE" –activation-email="EMAIL"
I've tried many permutations of my account data here using both invocations - using the activation code from the products page on the Xamarin store. No matter what though, this error occurs:
\mandroid.exe : monodroid: error XA9997: Incomplete data provided to complete activation
In the "problems activating?" section of the products page, it says this:
In Mono for Android 1.0.21316 and later, if activation within Visual Studio fails then a MfaActivation.dat file will be created within the Documents folder. Select this file below.
Perhaps there's some way to force this file to be created by mandroid.exe? That would be very helpful. While I imagine that offline activation is the only way to make this work, I would accept any answer that involves uploading MfaActivation.dat or otherwise invoking the online activation machinery as well.
Update - I'm afraid that the below steps no longer work. Xamarin has updated their activation system to activate by a different method for newer versions.
In the end I had to install Xamarin Studio as part of the Chef configuration and just instruct administrators to manually activate the software as part of creating a new build node. I had no luck trying to reverse engineer a fix, and if I did, it would probably just break again.
It turns out that I almost had it correct. The second invocation I specified is actually the correct way to call this command but the -- part was apparently converted to a – token by some blog software somehow.
The --activate verb will perform an online activation with Xamarin's servers, so I'm still not sure how you'd do it without an internet connection.
For reference, here is how I did it:
mandroid.exe -v --activate --activation-name "(NAME)" --activation-phone "(PHONE_" --activation-email "(EMAIL)" --activation-company "(COMPANY)" --activation-code "(CODE)"
I'm not sure about the significance of the -v switch, but perhaps that would make it output debugging info if there was a problem.
You must enter all the information exactly as specified on your products page - select one of your licenses and select "problems activating?". However, you will need to enter the licensee name - i.e. the user who owns the license in the --activation-name parameter which must correspond to the --activation-code parameter.
After doing this you can call mandroid with the --activated switch which returns an exit code:
PS> & .\mandroid.exe --activated
PS> $LastExitCode
0
You will also be able to reload the products page and you should see that your license for the chosen user has a new computer registered to it.
This does use up another activation but if you e-mail the support team you can sign the build server agreement and then I assume they can set you up with additional activations for your build nodes.
It's a shame that this wasn't documented better because this has wasted my time for several days. Hopefully this will be helpful to someone else with the same situation.
From Xamarin documentation, we can see
http://docs.xamarin.com/guides/cross-platform/ci/configuring_tfs/
"Visual Studio Professional (or greater) must be installed on the Team
Foundation Server along with licensed copies of Xamarin.Android and
Xamarin.iOS to support development of Android and iOS mobile
applications via the Team Foundation Server."
So I assume that in all cases you need to have VS + Xamarin products installed and activated.
I might be wrong, so the best way is to contact Xamarin support, http://xamarin.com/support
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.
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.
I have made a simple installer application in Delphi, nothing fancy. Basically I include files into the Exe, and then extract them to a user specified path.
I stumbled across a problem however, and I have noticed this works with ANY Windows Executable, it does not matter if it is an installer or not.
If an Exe is named, or contains the following words in the filename, "Setup", "Build", "Install" and maybe others, then.. whenever the Application is run and closed, Windows pops up a Product Compatibility Assistant dialog, saying the Application may not have installed correctly.
This is a problem, as even though the Files from my installer have actually extracted, and in my eyes the installer has done its job, Windows is complaining about it.
The only idea I have regarding this, is that Windows must check the filename of the Applications when executed, and in this case has identified it as an Installer. Windows must of then set a flag or something on the System, my Installer must then update this flag to say that the installation was a success?
Windows does not complain about this when debugging from the IDE, so it cannot be code related, it must be the OS - this only happens when launching the Application from Windows, not Delphi.
You can try this easily, either create an Application or rename one as Setup.exe, Run it and then close it - wait a few seconds and the Product Compatibility Assistant Dialog will show.
I don't know where to start investigating how to stop this dialog, or where a setting may be to tell Windows the Installer was completed correctly.
Appreciate your thoughts and solutions thanks.
If I recall correctly, this happens when your install app does not include an application manifest. When UAC was introduced, MS introduced a heuristic detection for installers and shows the UAC elevation dialog. The heuristic checks for names like setup.exe, install.exe. The simple solution is to include an application manifest. If it is an installer you probably want to use the requireAdministrator setting.
The feature is known as Installer Detection and is discussed here.
For what it is worth, I would always build an installer with a dedicated install tool like InnoSetup for example.
As David pointed out, MS uses some fuzzy logic to try to guess if the program is an installer. I wouldn't rely on this, as this is only for supporting legacy installer applications.
All new applications should have a manifest file, specifying whether it requires elevated privileges.
If an application has a manifest file that includes the requestedExecutionLevel directive, then Windows does not attempt Installer Detection.
Any program that is detected as an installer program but does not add a registry entry to the Add Remove Programs section of the registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall) will get the message "This program might not have installed correctly".