I have custom bootstrappers for SQL Server 2008 R2, .NET Framework 3.5, .NET Framework 4, etc. I am using Visual STudio 2010's Deployment project to deploy a .NET 4 application. I know these are going away.
Is there a way I can specify a bootstrapper to Fail if the user does not have specific Windows Privledges? SQL Server's Setup seems to take care of this on its own, but gives very cryptic error codes and texts that are hard to trace for users. I know that I can set Bypasses for Windows versions, and SqlCheck.exe performs some sort of version check. Would I have to create my own application that checks the user's permissions, and the bootstrapper could check the return code of that, similar to SqlCheck.exe?
Can this be accomplished using the Bootstrapper Manifest Generator, and is the BMG even supported by Visual Studio 2010? Appears to not be supported anymore, but I"m not sure if there's anything specific to VS 2010 / Windows Installer 4.5
http://archive.msdn.microsoft.com/bmg
The most you can do with the standard Visual Studio bootstrapper is to check the AdminUser property value. The predefined .NET Framework 4.0 Client Profile prerequisite uses a similar condition. You can find its manifest in this folder:
C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\DotNetFX40Client
This should also be supported by the bootstrapper manifest generator.
But, and this is a big one, on newer Windows versions all users can get Administrator privileges through elevation. So from the installer point of view, any user is seen as an Administrator, even if he's not.
So this approach is pretty much useless on Vista or higher.
You could try creating your own custom EXE bootstrapper which handles prerequisites and checks user privileges. But you will most likely encounter the same problem.
From my experience, the best approach is to let each installer elevate itself if necessary. Most of them have built-in mechanisms for this, especially the ones from Microsoft.
If you encounter problems with this approach, I'm pretty sure they are not caused by privileges. Most likely your prerequisite is not configured correctly (for example an incorrect command line).
Related
We are migrating our applications from 32 bit to 64 bit. And also .net framework 3.5 to 4.0.+Visual Studio 2008 to Visual Studio 2010
Aspart of migration we created all msi's in 64 bit with visul studio 2010. we had a problem while installing them.
we are getting System.BadImage error for the msi's which are having some customaction condigured in depolyment project. Due to this error installation rolled backed.
Root Casue Identified:
For doing customaction we have projects with installer classes While installing those using msi we caught that error.
When ever we get that error.We just tried installing that .exe manually using 64 bit visual studio commandLine with installUtil.exe command. it successfully installed.
But when we are using 32 bit visual studio commandLine with installUtil.exe, we end up with the same error.
So problem is when ever we are using msi its picking the 32 bit installUtil.exe eventough the msi is 64 bit which is causing the problem.
Tried Solutions:
1.Tried debugging the installer class using Debugger.Launch(). But before hitting the point we end up with error.
2.Try to edit the Database table of msi with orca editor to pick the correct version of installUtil.exe. But failed with other error.
Question:
1.How can we modify our solutions to pick the 64 bit installUtil.exe?(if we can do this)
Rule #1: Don't reinvent the wheel. Avoid CA's wherever possible.(See PhilDW's answer)
Rule #2: When you really must use a managed custom action don't use InstallUtil. Use Windows Installer XML (WiX) Deployment Tools Foundation (DTF) instead.
Rule #3: Write custom actions that follow MSI's transactional model (Install, Rollback, Commit) whenever possible.
Rule #4: Write data driven, declarative (custom tables) custom actions whenever possible.
Rule #5: Honor the security model of MSI ( custom actions that change data must be deferred in the system context )
Rule #6: Test the !#Q%Q! out of your CA's. Make sure that install, uninstall, reinstall, cancel (rollback ) and upgrade (and upgrade rollback), repair and silent installs all work as expected. Hint: Rule #1 exists because you get this for free when you don't write custom actions.
Reference:
Deployment Tools Foundation (DTF) Managed Custom Actions
This might be the issue:
http://blogs.msdn.com/b/heaths/archive/2006/02/01/64-bit-managed-custom-actions-with-visual-studio.aspx
You don't need installer classes. Visual Studio setups to generate MSI files are not in newer versions of VS, so you should use a tool that uses the standard methods of installing services, ServiceInstall and ServiceControl being the underlying tables in the MSI file.
I just completed my application development efforts on a D2D1 application using Visual Studio 2010 IDE in C++. I was exploring different ways of creating a package from this and used the built-in Visual Studio installer/setup. The setup project compiled smoothly and an install file was created. I was also able to successfully install the application according to my requirements. However, when I install it in the default location (which would be my preferred location - C:\Program Files(x86)), the application refuses to launch. Here is the debugging I was able to do so far:
Installed in C:\Program Files(x86): Application does not launch normally.
Installed in C:\Program Files(x86): Application launches when "Run as administrator"
Installed in a location other than %ProgramFiles% or %ProgramFiles(x86)%: Application launches normally without having to "Run as administrator".
I have tried cornering the error cases, but don't have anything conclusive or convincing so far, which is why I am seeking the experts help here. What I have done further:
Used Dependency Walker x86 version to figure out where/what the dll calls are through the profiler. It did not provide me with anything concrete - depends.exe believes my application has delay-load dependent modules GPSVC.dll and IESHIMS.dll and I am fairly certain that I don't need those. The profiler also indicates a CRT 0xC0000417 error - but it is difficult for me to say if it is related at all.
I do have a manifest defined for my visual styles as a pragma. Removing this did not help.
If this helps - my C++ project manifest file options in the Linker settings looks like this:
Generate Manifest - Yes
Allow Isolation -Yes
Enable UAC - Yes
UAC Execution level - As invoker
UAC Bypass UI Protection - No
I have converted all CRT functions to it's secure version (sprintf -> sprintf_s) as recommended by MSDN documentation. Is this even related here?
I have tried simply copying the .exe to %ProgramFiles(x86)%. It did not help - so it appears that my installer is not the one creating the problem.
I use _dupenv_s in several places within the code to retrieve %COMSPEC% , %TEMP% etc.
Any pointers to how I can proceed further with the debug is highly appreciated. I did read around about this and some experts suggest incorrect string handling or large or invalid directory names; but I don't see that as relevant in my case since the issue is unique to launching the application normally under %ProgramFiles(x86)% .
Other details:
* OS Windows 7 - 64 bit, Vista with latest SP - 32 bit
* Visual Studio Professional 2010, C++ Project with .Net client profile target
Visual Studio Installer; Target platform 32 bit
* Nature of application - Direct2D based
Pardon me if I did not use the correct technical terms. I am a novice in application deployment.
That is correct Viswanathan, you cannot write to Program Files/Program Files(x86) if you are not running from an elevated process.
If your application needs to write custom settings in a file when it is launched you should create a dedicated folder for it under CommonAppDataFolder
I'm using the Visual Studio Setup project. If I go to the properties of the Setup project, it lets me choose which pre-reqs are required, at which point I choose the C++ Redistributable.
On some systems, this works fine - but recently my users are reporting that the install failed because "A newer version of Microsoft Visual C++ 2010 Redistributable has been detected on the machine."
What's the proper way to do this? Is Visual Studio's detection fouled up somehow and unable to detect C++?
Yuck, this is ugly. I was wondering what would happen after Microsoft gave up on the side-by-side install of the runtime DLLs for VS2010. Seems clear, the interwebs are full of this installer error. The biggest victim seems to be Microsoft itself with Streets and Maps failing to install.
I'm not aware of any security patches for it so I have to guess that you haven't updated to SP1 yet. And your customers use a product of a vendor that did. This is a battle that you're always going to lose some day. Do consider taking advantage of the app-local deployment for the DLLs, copying them in the same directory as your main EXE. Simply copy them from the vc/redist directory before putting the setup package together, no need to tick the prerequisite. You'll need:
msvcr100.dll and msvcp100.dll for the regular CRT
atl100.dll if you use ATL
mfc100.dll, mfc100u.dll, mfcm100.dll, mfc100u.dll if you use MFC (u = Unicode, m = managed)
mfc100xxx.dll where xxx is the 3 letter language code if you use MFC on a non-English machine
vcomp100.dll if you use OpenMP in your code.
Only disadvantage is that they won't get updated if there's a security patch. That could be an advantage too, depending on what color glasses you wear. If you're uncomfortable about it then keeping the machine that creates the setup package updated, including enabling Windows Update, is an important requirement.
The default Visual C++ 2010 Redistributable uses a Product Code for detection. So Visual C++ 2010 SP1 Redistributable is not detected as installed. This is why the package tries to install it and fails.
A good solution is to create your own custom prerequisite which uses a better detection criteria. Here is an article which may help you:
http://blogs.msdn.com/b/astebner/archive/2010/05/05/10008146.aspx
Visual Studio setup projects do not support custom prerequisite creation. However, it can be done by manually generating the required manifests.
You can find the manifests structure here: http://msdn.microsoft.com/en-us/library/ms229223(VS.80).aspx
These manifests can be generated automatically with the Bootstrapper Manifest Generator tool.
After generating the package manifests, you can add all these files (including the package) in a separate folder in the Visual Studio prerequisites folder, for example:
C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\
This way Visual Studio will show the prerequisite in your setup project properties page.
I am quite new to Windows Installers, i faced some problems, but finally accomplished what i wanted. One important question remains for me. I can't figure out where i can download or how to create or update bootstrapper packages.
My application needed SQL server compact 3.5 and the bootstrapper package was installed on my hard disk by VS2008. What i wanted was SQL server compact 3.5 SP2 and i also needed an offline installation. I searched a lot on the internet, but could net figure out how to upgrade my SQLCE bootstrapper package to SP2, moreover i could not figure out where to download, create or upgrade these bootstrapper packages like e.g. .Net Framework myself.
I do know how to use Bootstrapper Manifest Generator in case i need to create a bootstrapper package, but to use BMG to create Microsoft packages i think i a short on information (i could not find too musch about this as well) to create correct package and product XMLs.
Maybe i am just silly, but if someone could explain me in what way i can update or upgrade my offline bootstrapper packages in ht Microsoft SDK folder, i will be grateful. It will save me a lot of misery next time.
Thanks a lot in advance!
Svatja
P.S. I obtained the SQLCE SP2 package by downloading and installing VS2010 express on my Vista test PC.
As far as I know, there is currently no simple answer to the bootstrapper problem, but I'll try to point you to some possible solutions:
I'm not familiar with the Bootstrapper Manifest Generator, but my understanding is that the VS bootstrapper is not very flexible. I remember I looked at it briefly and decided against it.
Since your question is tagged Wix I'll assume that you're aware of Wix 3.6's "Burn" bootstrapper currently in development. The present recommendation is that if you're planning to ship in the fall, you should pick up the Wix 3.6 dependency and start working with Burn. I consider this a very risky choice since there is no guarantee that Burn will actually be done in time.
I've used the Microsoft .NET Framework Setup.exe Bootstrapper Sample as the basis of a simple bootstrapper before. The idea here is to replace the logic to check for .NET Framework with logic to check for the SQL server you require. Then either install SQL Server by executing the redistributable, or skip the SQL Server installation and go straight into your MSI installation.
If you want to provide a user experience beyond regular MSI dialogs, you could look into creating an external UI, although documentation for this is scarce. I recently completed a WPF external UI bootstrapper. The way I tackled this was creating a C# version of the MsiSetExternalUI Handler Sample using Wix's DTF, and then integrated it into a WPF wizard based on this MVVM Wizard sample.
I hope that can at least get you started on choosing the right bootstrapper solution for your deployment. Good luck!
I have an app that on first installer run needs a boostrapper where you can choose the language of the installed app, install .net framework if it's not there yet and some other prerequisites.
I've taken a look at the WiX How To: Install the .NET Framework Using a Bootstrapper
but I don't see how to use this for other custom prerequisites.
What's the best bootstrapper to use for this?
After the app is installed we have an update check on the app startup. if a new version exists we need to download it and upgrade the software.
This wouldn't be a silent upgrade because the EULA and some other stuff might change in the meantime so we still need a GUI for those checks in the updater msi. So i'm considering different options on how to do this.
My first thought was to have 2 separate installers.
The first one would be with the bootstrapper and full GUI, the other would be with minimal GUI for updates.
Is there a better option?
I'd also like the access to the update installer on the to be limited to only users that have the software actually installed.
i'm not quite sure of the best way to do this.
I'm familiar with the WiX upgrade process itself with the upgrade code etc... so that's not the issue.
I'm just looking for a way to design all this in the best way possible.
Any ideas are appreciated. I'm using WiX 3.0.5419.0 from Visual Studio 2008.
I've taken a look at the WiX How To:
Install the .NET Framework Using a
Bootstrapper but I don't see how to
use this for other custom
prerequisites.
You can use the same technique (i.e. the msbuild GenerateBootStrapper task) to install custom prerequisites, but you'll have to author your own bootstrapper packages.
One way to do this is to study the existing bootstrapper packages in C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\ (or the ones in the Windows SDK) and read the documentation of the Bootstrapper Manifest XML format. The bootstrapper generator tool might also be helpful.
As for auto-updating your application: it's not supported by wix. I believe there were once plans to add this functionality under the name clickthrough, but I don't think those plans ever matured. If they did, I can't find any documentation about it.