I'm trying out Powershell DSC as a way of automating deployments. We have an EXE installer created by Installshield for a server application, and need to ensure the latest version is installed.
Installshield guidelines (http://www.flexerasoftware.com/producer/resources/white-papers/is-msipatches.html) suggest that the Package Code should change for every build, the Product Code should stay the same between minor versions, and the Upgrade Code should always stays the same.
Is there a way of telling Powershell DSC to install a particular minor version, i.e. to make sure that the Package Code matches exactly?
I'm using the following to create the MOF, but when I run it, it detects the Product as already installed and doesn't do anything, even though it's a different Package.
Package MyApp
{
Ensure = "Present"
Name = "MyApp"
Path = "\\path\to\specific\version\of\setup.exe"
ProductId = ''
Arguments = "/V`"ADDLOCAL=ALL /qb`""
}
The package resource will declare the resource as correctly configured if the package is already installed. So it will not work for your specific scenario. You will have to write a custom package resource or extend the existing one. If you want to modify feel free to fork this repository and extend the functionality https://github.com/PowerShell/xPSDesiredStateConfiguration You can also open an issue for someone to pick up and fix the same.
Related
I'm new to wix/wixsharp and bootstrapper. I created an installer and providing ProductID, UpgradeCode and version. Installer is working fine but when I'm creating new installer and giving different version it is simply allowing user to install the another version of application and bot can be seen in program files.
If I use the same file that was used earlier to install, it gives option to uninstall as expected but when I use the upgraded file it does not give upgrade or repair option.
Can anybody help me with this. Here is the code I'm using
project.UpgradeCode = new Guid("9fa9fcf6-e807-404d-a67a-d66f1a60ca53");
project.ProductId = new Guid("0b2d7210-32ce-4095-9c46-aaccb1bf0733");
project.Version= new Version("1.0.209.10040");
project.MajorUpgrade = new MajorUpgrade
{
Schedule = UpgradeSchedule.afterInstallInitialize,
DowngradeErrorMessage = "A later version of [ProductName] is already installed. Setup will now exit."
};
In 2nd build I'm just changing Version("1.1.209.10040") keeping everything else same.
Please let me know if any other part of code is required as I'm really new I'm not sure I shared all the necessary information.
If you're trying to do a major upgrade you will need to change the ProductCode. Whenever you're building an upgrade you should refer to the Windows installer Upgrade page that MS publishes. I don't know if there is a specific one for WiX but the same concepts still apply.
This worked for me. I changed ProductId and then I am able to auto-upgrade my Product based on version# (first three parts).
project.ProductId = Guid.NewGuid();
We have a few VMs in Azure and we rely on the PowerShell DSC extension to deploy our code to the machines. I want to make sure that this extension is not updated automatically so that our code that uses functionality from this extension don't break without we knowing about it first.
The problem is that we have some deployment scripts that read the extension's status codes/messages and do custom logic based on them. When the extension was updated from 1.4.0.0 (which is the version that the plugin was on when we first started using it) to the version 1.5.0.0, some of the status messages changed and our script stopped working. This completely broke our deployment process and we had to do an emergency update on our scripts to be compatible with v1.5. Now that version 1.7.0.0 was released the same exact problem happened again. Some new status codes were added and I had to update our scripts or we would not have a working deployment pipeline.
Is it possible to specify a manual update process for these extensions? Their installation and update seem to be completely automated. Ideally, I'd like to be able to update them on a case by case basis after testing our scripts against the newer versions first, so that our deployment process is not halted because of that. Bonus points for anyone who manages to find up to date documentation or some kind of release notes document for this extension in particular, as I could find none... I was just surprised to see that version 1.7 was installed today when I got an error from our script, and was lucky to know exactly where to look for the status changes.
The default behavior for the DSC extension handler is to update to the latest version. If you want to tie yourself down to a specific version, then you can do so with the following cmdlet (currently there is no provision from the UI)
Set-AzureVMDscExtension -Version
Please note that we are also try to ensure updates do not cause issues. We are not there yet but we would certainly like to get there so everyone is automatically updated.
I am wondering whether it is possible to update package that was installed with /x flag?
For me it seems that it is not possible right now. What I mean by updating is making packages.config change with greater version of given package (done by nuget.exe update SolutionName.sln)
What is the flow of update operation? Does it look inside nupgk of actually installed package? Or it just search for version within directory name?
When version in directory name is missing is there a problem with version comparison?
I need precise explanation.
Note:
I use nuget 2.8.50224.430
I created identical thread on nuget codeplex here:
https://nuget.codeplex.com/discussions/543299
I think I managed to answer my own question.
While waiting for response I decided to look at nuget.exe sources and find how is version from installed package gathered.
What I realized:
1. Version is taken directly from packages.config.
2. nuget update command looks for PackageName.PackageVersion.nupkg in packages directory.
3. When wanted file does not exists, update cannot be completed (it is aborted).
I tried to change code to use directory and package name without version.
It is possible but it will be better to request another flag for that purpose.
For curious: PathResolver is created in UpdateCommand.cs
var pathResolver = new DefaultPackagePathResolver(sharedRepositoryFileSystem);
You can pass false as second argument to omit version in path concatenation.
I have developed an Excel XLL using ExcelDNA and C#. I am at the point where I would like to begin testing the deployment, but cannot find much information that actually provides steps that work.
My project was developed as a Class library with ExcelDna references. In the .dna file, I have the code below that will pack all resources into a packed version of the XLL (i.e. the Pack="true" attribute).
<DnaLibrary Name="ExcelXLL" RuntimeVersion="v4.0" Language="C#">
<ExternalLibrary Path="ExcelXLL.dll" LoadFromBytes="false" Pack="true" />
I would like to deploy the packed XLL to the target machine in the path:
%APPDATA%\Microsoft\AddIns
In order to automatically register the XLL with Excel, I need to add a registry key that depends on the version of Excel that the user has.
For instance, on my computer (Windows 7 64 bit running Excel 2007 32-bit), I would need to add a registry key to the following path:
HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Excel\Options\
The key would be type REG_SZ with the name OPEN (or OPEN1, OPEN2, etc.) and the value
/R "ExcelXLL-packed.xll"
I have 2 problems though. The first is in determining which version of Excel that the user has to get the correct path and the 2nd is to determine the correct OPEN version that I need to create (for example, if the user already has OPEN, OPEN1, and OPEN2 then I would create an OPEN3 key).
I am trying to do the installation using either the Setup and Deployment project or a InstallShield LE project and cannot determine how to go about this. Does anyone know how to do this or a better way of doing it?
EDIT 1:
I have done a great deal of research on this and have looked at several windows installers.
In the Package and Deployment and InstallShield LE, I can get the install/uninstall to work by putting an installer class into my class library and bundling project output with the install. In this approach, I handle inserting/removing the registry key using the installer class. The problem that I have is that the user must uninstall first before running a new install (no update capability).
I downloaded the Setup Factory demo version and can get install/update to work but cannot do the framework check (not shipped with the demo). Also, the uninstall fails (though I may be able to get this to work with some more investigation).
I am interested in using the WiX installer, but would like to know if anyone has a sample of how to perform the deployment using WiX. I would also like to know if I need to use the installer class or if there is a different way to handle the search for the OPEN[n] key under HKCU\Software\Microsoft\Office[Version].0\Excel\Options. If I were to use the project output to enable the installer class, then I need to have 2 separate target directories (one under Program Files for the basic project output and one under %appdata%\Microsoft\AddIns for the packed XLL).
Any help is greatly appreciated.
Thanks,
Lee
To detect Excel 32-bit vs. 64-bit, you can check the registry: Detect whether Office is 32bit or 64bit via the registry
For the OPEN, OPEN1, OPEN2 etc. you typically need a Custom Action in the install script that enumerates the keys.
Using IsWix and Wix 3.7, I was able to resolve this.
Useful links for how to register the components are as follows:
For generating a C# class to handle Windows Installer Custom Actions:
http://www.codeproject.com/Articles/132918/Creating-Custom-Action-for-WIX-Written-in-Managed?fid=1599130&df=90&mpp=25&noise=3&prof=False&sort=Position&view=Quick&spc=Relaxed&select=4131367&fr=1#xx0xx
http://blogs.msdn.com/b/jschaffe/archive/2012/10/23/creating-wix-custom-actions-in-c-and-passing-parameters.aspx
For setting the property of the CustomAction.config file to Content
WIX Custom Actions built for .Net Framework 4.0 does not work? Ways to resolve?
EDIT 1:
For general knowledge on WiX (Very important)
http://channel9.msdn.com/blogs/scobleizer/wix-team-the-most-used-piece-of-software-at-microsoft-and-its-open-source#Page=2
I have a setup project with InstallShield 2010. I'm deploying a configuration file during installation. However, when uninstalled, InstallShield decides to delete it (which is normal).
The question is, is there a way to keep the file on the hard disk even after the application in uninstalled? I don't want to reconfigure the application every time the user uninstalls/installs.
Edit: I'm using MSI project.
You don't say what project type you are using. Either way, put the config file in it's own component. For MSI projects, set the Permanent attribute to true. For InstallScript projects, set the Uninstall attribute to false.