I have problems with my InstallShield projects, that are using InstallerClasses, during the Major Upgrade. The setup is calling the old version InstallerClass or just throws error 1001.
I decided to use the DTF technology, but I am unable to link the generated *.CA.dll file to the "DLL Filekey" property. I am linking the project as a "primary output".
Any idea how can I use the DTF custom action project and link it to Basic MSI Installshield 2012 project? I want to avoid referencing the CA file directly because I am creating automated builds.
Many thanks,
Marek
Related
I have done the following to create an Alea GPU project in Visual Studio 2012 Professional:
File > New > Project > F# Application
Updated NuGet Package Manager to latest version
Tools > NuGet Package Manager > Console
PM> Install-Package Alea.CUDA
PM> Install-Package Alea.CUDA.IL
Installed license using these instructions: http://quantalea.com/static/app/tutorial%5Cgetting_started%5Cinstall_license.html
Copied the code from here https://github.com/quantalea/AleaGPUTutorial/blob/master/src/fsharp/getting_started/ParallelSquare.fs into my main project file.
Build Solution.
I get the following errors:
The lines numbers and file from the GitHub link above correspond with each other.
I'm new to using Alea GPU, Visual Studio, and F#. I've tried doing what I could with the resources I have available. Although the the Alea GPU website explains what to do (install Alea through NuGet, install license, provides code, etc.) it might be targeted to users who have experience working with Visual Studio. It's also worth mentioning I have CUDA drivers installed on this machine.
I have also followed the instructions on this page, but it seems like it's still under construction: http://quantalea.com/static/app/tutorial%5Cgetting_started%5Ccreate_new_project.html. I'm not using Fody since I won't be using C#.
Thanks for reporting the web site problem. Yes, our document are under constructing. I tried your steps and I figured out how to do it correctly, which I will show you later. The issues you met are mainly because:
You are using VS2012, which by default referencing FSharp 3.0, which is a little out-of-date, we suggest to use FSharp 3.1
You forget to reference other assemblies which is used in the code, such as NUnit and FSharp.Charting
Alea.CUDA.Fody doesn't means to work with C#, it means to do AOT compile on GPU code. It uses Fody plugin to compile GPU code during MSBuild process, so your appliction doesn't need to compile GPU code in runtime.
Now, here are the steps:
Open VS 2012, upgrade nuget plugin, then new F# console application project
Expand "References" in solution explorer, and remove the FSharp.Core reference (since it is FSharp 3.0, we will replace it with new 3.1)
Go to "Package Manager Console", install some nuget packages which is used in the code:
Install-Package FSharp.Core
Install-Package FSharp.Charting
Install-Package NUnit
Now we will install Alea.CUDA.Fody (which will install Alea.CUDA by dependency). But since Fody plugin has to run some powershell script to create an FodyWeavers.xml file to configure Fody usage, and this script doesn't work well with F# project (it works with C# project). The workaround is simple, just click "save all" in VS2012 before you run Install-Package Alea.CUDA.Fody. You will see some red error in the package manager console, that is fine, it is just the Fody plugin's script doesn't work well with F# project. You can safely ignore it. After install Alea.CUDA.Fody, a file FodyWeavers.xml file will be added to your project, there you can configure how you will do the AOT compilation. I suggest you add a setting to show verbose information: <Alea.CUDA Verbose="true"/>
Now you need add some common references, since the package FSharp.Charting uses them. To do that, right click your "References" in solution explorer, and choose "Add Reference...", under "Assemblies" -> "Framework", select these assemblies:
System.Drawing
System.Windows.Forms
System.Windows.Forms.DataVisualization
Now your project is set. Please Change the building configuration to "Release".
Now let's add the source file. First right click Program.fs in solution explorer, and select "Add above" -> "New Item...", select F# source file, name it ParallelSquare.fs
Copy https://github.com/quantalea/AleaGPUTutorial/blob/master/src/fsharp/getting_started/ParallelSquare.fs into that new created file
You need modify one place: https://github.com/quantalea/AleaGPUTutorial/blob/master/src/fsharp/getting_started/ParallelSquare.fs#L139 , change this to WorkerExtension.Launch(worker, <# squareKernel #>) lp dOutputs.Ptr dInputs.Ptr inputs.Length , the reason is, the Launch method is an extension method, which the FSharp compiler in VS 2012 doesn't support it well, so we call that extension method directly (So I suggest you to use VS 2013).
Now in your Program.fs file, call the test in main function: Tutorial.Fs.quickStart.ParallelSquare.squareChart(). and then you can press "F5" to run it.
After this, I suggest you read http://quantalea.com/static/app/manual/compilation-index.html where explains the intallation, the AOT vs JIT compilation, etc.
I have a software that is coded in C#. It depends on two(!) third party dll which require Visual C++ 2008 and Visual C++ 2005 redistribute. Originally the installer was built in InnoSetup with all "vs200x_sp1_vcredist_x??.exe" embedded and run on install time. However since it lacks of some advanced features we decided to migrate to Wix Toolset.
The problem is, MSI was running in a more restricted environment, so I didn't figure out what is the best way to require those redistributable file being executed properly. I was tried to use merge modules instead but it didn't work - I can see that the files were installed but dependency walker shows that dll is still not link to the right version.
I think that WinSxS makes things worse at least in this case, since the software keep failing with some error message regarding "Windows Side by Side configiration (14001)" when I use the merge module approach.
So the question is:
Are there any way to build a MSI that runs a exe that install some prerequisites? I wouldn't mind those prerequisites being downloaded or just embedded.
I know that WinSxS information is stored in the manifest of the dll. So if I was permitted to remove the manifest information by the third party company, and use dynamic dll loading instead the problem could be resolved. However is this legitimate? Since I will then need to embedded the Microsoft dlls directally in the msi.
I have noticed one of the dll's manifest says its required version is "9.0.21022.8" but the one in my MSM file is "9.0.30729.6161". Is this the issue? If so can I resolve the issue by I modifying the manifest to allow the right version? I don't think this will cause the dll not working, anyway.
The msi file should install only your software. If you need to install pre-requisites, you should use a bootstrapper for it. Bootstrapper's responsibility is to install pre-requisites and it's not a task of your msi.
If you see that wix bootstrapper is complex you can try on a simple bootstrapper like the dotnet installer bootstraper. you can download it from
http://dblock.github.io/dotnetinstaller/
I have created an MSI installscript project in Installshield. I went to Project Assistant>Application Files, then added the application files(package) and built Setup.exe to install.
After installed these files, I went back to Project Assistant and added some application files, then i changed the product version for updating. Finally, i built the Setup.exe again. When i run the Setup.exe, the automatic update (Upgrade Window Installer Setup) asked me to update a new version. After finishing, I checked Program Files(x86) and the updating didn't do anything, the old package was still here.
How can i update my new package? Is there any way to disable the Upgrade Window Installer Setup?
Thanks for the help.
In my humble opinion, most likely, you added new files to existing Component with keypath, which didn't change. Also you should check "Add\Remove Programs" snap-in in Control Panel to see if upgrade was applied - there should change version of your product.
So, I recommend you check Components, and re-allocate files to new Components if I had right. Also please read more about Components and Files. Could start from here.
Two words about InstallScript MSI project. From InstallShield documentation: Because this project type uses two different engines, it is more complex than pure InstallScript or Basic MSI installation projects. It is recommended only for advanced users.
So, if possible, use Basic MSI project - it's a bit simpler than InstallScript MSI for begginers.
I am not a full time programmer, but have to do a little bit to build tools to support my job. I have finished writing my application which I now need to deploy.
I do not want to use "ClickOnce" as I need to alter files in the 'local' folder at configuration time. My understanding is that if I use the Publish option under the Build menu, then I am using "ClickOnce".
My research has led me to believe that "You do this by adding one or more deployment projects to your solution". MSDN then states, that to acheive this I need to select 'Add Project' and "In the resulting Add New Project dialog box, select the Setup and Deployment Projects folder."
The problem is, I do not have such an option ?!
Can someone shed some light on why this would be the case, and how I go about fixing it. I have spent half a day googling and cannot come up with a way forward?
Details of Project and System are as follows:
Environment: Visual Studio 2012 Express for Windows Desktop.
Current Project: Windows Form Application.
Op Sys: Windows 7 Professional.
Correct though its advice may be, that is an old tutorial that you're reading. It is probably referring to Visual Studio 2010.
That option has been removed in VS 2012. You will need to use an alternative tool to build your installer. For example:
WiX
Inno Setup
InstallShield
…etc.
I strongly suggest looking at Wix#. See http://www.codeproject.com/Articles/31407/Wix-WixSharp-managed-interface-for-WiX. If you are doing your coding in C#, Wix# this would probably be the most simple and comfortable skill set to add, and it is free and would directly integrate into the Visual Studio environment you are using.
More info at the CodePlex home page for Wix#: http://wixsharp.codeplex.com/
For C# developers needing to create a Windows Installer MSI to deploy their app, Wix# is perhaps the best replacement for the "Packaging and Deployment" project type that Microsoft removed from Visual Studio starting with VS2012. Wix is a C# front end for the WiX (Windows Installer Xml) Toolset. Using Wix# allows building a complete Windows Installer MSI in the C# language.
Wix# is useful for a broad range of installation/deployment scenarios, and lends itself reasonably well to Continuous Integration scenarios. There are Wix# examples for deploying Windows desktop applications, for installing Windows Services, and installing ASP.NET websites, and many more types of installations.
The question mentioned a need to install applications on Windows 7. Wix# supports this environment, and handles typical installer requirements, and the Wix# installer code for simple projects is indeed simple. For application installs that are more complex, and require advanced features, Wix# can tap into the power of the full WiX Toolset when needed. For example, when installing a .NET application, a typical requirement would be to install the application exe and dll files, and tailor some .NET configuration files and/or registry entries on the target system.
Below is an example of the C# code for a simple Wix# installer that installs an application on a target system, and modifies some configuration files. This example assumes that you have written a utility named "TailorMyConfig.exe", e.g., a simple C# program that uses ConfigurationManager.AppSettings routines, and you are deploying this exe along with your app.
using System;
using System.Windows.Forms;
using System.Diagnostics;
using Microsoft.Deployment.WindowsInstaller;
using WixSharp;
class Script
{
static public void Main(string[] args)
{
var project = new Project("MyProduct",
new Dir(#"%ProgramFiles%\My Company\My Product",
new File(#"Files\Bin\MyApp.exe"),
new File(#"Files\Bin\TailorMyConfig.exe")),
new ManagedAction("UpdateConfigFile"));
project.Id = new Guid("6f330b47-2577-43ad-9095-1861ba25889b");
Compiler.BuildMsi(project);
}
}
public class MyCustomAction
{
[CustomAction]
public static ActionResult UpdateConfigFile(Session session)
{
if (DialogResult.Yes == MessageBox.Show("Config file update ready to run.\n Update config file(s) now?",
"Config Tailoring Utility",
MessageBoxButtons.YesNo))
{
Process.Start("TailorMyConfig.exe", "Run utility to tailor config file to current system");
}
return ActionResult.Success;
}
}
Note that there are "better" ways to modify a config file using WiX XML features. For simplicity, the example above assumed a custom-written C# exe utility for modifying config files. I would suggest using WiX XML capabilities for doing this instead. You can incorporate nearly any WiX XML capabilities directly into your Wix# setup using the Wix# technique of "XML injection".
Remember, Wix# is simply a C# front end that emits WiX XML syntax. After Wix# has emitted the WiX XML (wxs file), that wxs file can easily be post-processed to insert additional WiX XML features. Then the resulting wxs file gets compiled by the WiX Toolset into an MSI.
For an example of using XML Injection to incorporate WiX XML features into a Wix# (C#)installation, look here In Wix#, how to avoid creating a physical folder on the target system, when deploying only registry entries?
In that question, see my answer that uses the technique of hooking up a delegate to the "WixSourceGenerated" event.
You could then use this XML injection approach to insert some WiX XML into your installer that would accomplish the config file editing. An example of some typical WiX XML to modify config files is here:
How to modify .NET config files during installation?
Another typical requirement of an installer would be to add or modify Windows Registry entries on a target system. Wix# provides direct support for that using the "RegValue" class. The advantage there is when using Wix# you also get a full "uninstall" capability for free, including uninstalling/reverting registry entries to the pre-install state. This is a natural result of Wix# being built on top of the WiX Toolset and Windows Installer technology. An example of a registry-only Wix# installer is here: In Wix#, how to avoid creating a physical folder on the target system, when deploying only registry entries?
The Wix# approach has been very useful in my environment, and it allows use of the familiar C# skillset without having to jump headfirst into the full complexity of the WiX XML installer technology.
I am writing an installer using wix. I have also written custom actions. But while installing the MSI the installation fails because the target system does not have MSVCR100D.dll
I am linking using /MTd option which is what the docs I read suggested for static linking.
Can anyone please let me know how to link msvcr100d.dll statically so that even if msvcr100d.dll is not present on the target system, my MSI installation succeeds?
The "D" in MSVCR100D.dll indicates that your native custom action DLL is a debug DLL. The "D" dependency won't be on the target machine unless they have various SDKs installed. Rebuild your DLL in release and the dependency will change to MSVCR100.dll
Also, since you are using WiX / Votive, there is a Visual Studio WiX C++ CA project type that creates the project for you. My experience has been that all of the default compiler and linker settings are good to go out of the box when you use that project type.
I have noticed the same problem. In my case, I am trying to debug my custom actions running in the context of the installer, so I do want to install debug versions.
The Visual Studio debug CRT DLL's are not redistributable, by Microsoft policy. Apparently, it seems furthermore that a 64-bit DLL compiled with Visual Studio 2010 using /MTd (static linking, debug configuration) produces output with a dependency on MSVCR100D.dll. In the 64-bit release configuration, as expected, compiling with /MT results in no dependency on MSVCR100.dll.
One solution is to install Visual Studio on the target test machine. Microsoft offers further suggestions here.