Creating package using Installshield 2012 Spring. To detect the erros enabling MSILogs by creating the reg key using 'voicewarmupx'. All log files are creating in Temp folder. My requirement is to change the logging location from Temp folder some other directory. Is there any way to achieve this, kindly suggest it will be a great help
There is no way to control the location of logs generated by the Windows Installer Logging key. All you can do is override the location manually, such as by providing an explicit location at the MSI command line. In some cases you can do this by specifying arguments in the Setup.exe tab of the Releases view. But beware: this makes it hard or impossible to avoid generating the log.
Related
I made some test sequences and a workspace in TestStand. I want to deploy those sequences and make a MSI based executable. However, I am not sure how can I include the files for Simple or Full Featured UI into the workspace and include it during deployment or call the UI content folder directly during the deployment.
Can anyone please help me?
Just insert folder with custom user interface into workspace https://www.ni.com/docs/en-US/bundle/teststand/page/tsref/infotopics/db_add_file_to_wksp.htm.
Then you will see inserted files in Deployment Utility.
But better practice would be to separate installers of user interface, and sequence itself. Because mostly you will do more changes/updates/fixes to sequence files, so you will need to redeploy just them.
This is a big undertaking, but may be worth it for you depending on the size of your company. TestStand has an API that you can use to develop a custom GUI. That GUI can then open any sequence file you like after being compiled as a C program that runs as an executable file.
I want to verify if certain exe files already exist in a merge module .ism (binary format). Is there a method of doing this without using InstallShield?
An *.ism file is really an MSI file with a changed extension. MSI files in turn are SQL databases stored as COM-structured storage files - a file system inside a single file with file streams for various content. This is the same format used in Office documents.
You can view MSI files with Orca from the Windows SDK: http://www.hass.de/content/how-install-microsoft-orca
Windows Installer XML (WiX) Deployment Tools Foundation (DTF) has an InstallPackage class available that exposes a FindFiles() method. This should be really easy to query the EXE. Just realize that being a merge module you won't know the full installation path as that's decided by the MSI generally.
Both of Chris's suggestions should work fine, as would using Orca. But it got me thinking there might be an even easier way using a tool called Merge Module Finder. It all depends on what you really want to do? Find files already in merge modules? Investigate what merge modules are in an Installshield file? It is not quite clear exactly what you want to do.
Though a bit clunky at times (I think the author hasn't updated it for the latest versions of Windows) it will help you look for a file in a bunch of merge modules interactively. You can also search for a registry value. Here is a screenshot:
I finally managed to get my application updating through installshield LE, without the user having to uninstall manually first, what I am now wondering is:
Can I get the installer to use the application settings from the previous install, so the users saved settings don't change, causing the user to enter their settings every time there is an update. But at the same time, add any new settings to the config file.
Is there anyway to get the installer to not update certain files, for example, the database file is held in a folder called 'db' inside the program files directory, I obviously don't want the users database getting overwritten with a blank one.
Thank you.
Im not sure what programming language you are writing in, but I had this concern with a C# application I wrote. I see 2 easy ways of doing it:
1) With C# you can setup application setting variables that get written to an XML file in the users Application Data (on WinXP) directory. The nice thing about this is that writing to and reading from the settings file is really easy through the API:
To save and store a variable:
Properties.Settings.Default.UserName = UserName_txtbox.Text; // save contents of UserName_txtbox to UserName setting variable
Properties.Settings.Default.Save(); // write variable to file
To restore a variable:
UserName_txtbox.Text = Properties.Settings.Default.UserName; //load contents of UserName variable to UserName_txtbox
Because the file that contains these are not included in the installation directory of the application, they are preserved.
If you are using a different programming language, you can try to implement the same concept.
Create a settings file that your program updates externally from the install location. (Perhaps it can be in the install location. Im not sure how your installer "updates". Does it replace files or uninstall the old version and install the new version automatically? Play this this to find out...)
Your settings file can be a simple txt file, a bin file, an XML file, etc. Anything that you can read and parse easily. Then you can load settings from the file when the program loads and save settings to the file when the program exits.
Using Visual Studio 2012, Azure SDK 2.1, I am trying to figure out the best way to create the csx folder for running in the azure emulator. My understanding is that the csx folder is not created until I package the Azure project. I can create a package manually from Visual Studio, but this is not an option for an automated build. The other option is to create the package using the msbuild command line. This seems a bit heavy handed as it will actually do a build which is more time consuming than just repackaging.
So, I thought that cspack might be a more lightweight option. However, when I call cspack with the following command line:
cspack.exe ServiceDefinition.csdef /copyOnly
I get the error: Need to specify the physical directory for the virtual path 'Web/' of role MyProjWeb.
But, I don't do anything like that when using msbuild. I have read a bunch of things about specifying the physical directory and some of the confusion that it can cause. So, I would prefer not to use it unless absolutely necessary, especially since I don't need to specify this when building from msbuild.
So, my main question is what is msbuild doing that cspack is not doing and how do I do the same with cspack?
My other question is, what is the easiest way to generate the csx folder for testing in the azure emulator?
Edit - Resolution
I thought that I would put down how I resolved this here in case it helps someone else. The big answer to my question (thanks to Chandermani and some other reading) is that CSPack with /copyOnly is basically a fancy xcopy to a folder structure according to some rules. If not using /copyOnly it then also does a fancy zip to create a package. Not complaining, it is fine that it is simple, but it is good to know this at the outset. You can use it for packaging anything for azure it is not tied to what can be built in Visual Studio, e.g. a PHP site. Using msbuild has the added benefit of only copying that files that are part of your web site deployment.
So, what I found when I got CSPack working and pointed at the mvc project folder is that it copied everything including source files. Which is not what I wanted. The solution that I could find is to first package the web site then point CSPack at the packaged files. If you do down this path then this link is very valuable as it describes it step by step.
So, it was either having an msbuild post-step in the Web project to package the files and then a post-step in my Azure project to cspack it or to have an msbuild post-step in my azure project to create the package (do cspack with the benefit of only including my web deployment files). Well, it seemed simpler and less error prone to just to have the one post step and let msbuild do the heavy lifting. So, the post step in my azure project is something like:
"C:\Program Files\Microsoft SDKs\Windows Azure\Emulator\csrun.exe" /devfabric:shutdown > NUL
"C:\Program Files\Microsoft SDKs\Windows Azure\Emulator\csrun.exe" /devstore:shutdown > NUL
if $(ConfigurationName) == Debug set CONSTANTSPARAMETER=DEBUG
if $(ConfigurationName) == Release set CONSTANTSPARAMETER=
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe $(ProjectDir)$(ProjectFileName) /t:clean;publish /p:Configuration=$(ConfigurationName) /p:TargetProfile=cloud /p:OutputPath=bin\Cloud$(ConfigurationName) /p:VisualStudioVersion=11.0 /p:overwritereadonlyfiles=true /p:DefineConstants="%CONSTANTSPARAMETER%" /verbosity:minimal /p:PostBuildEvent=
The first two lines shut down the compute and storage emulator.
The next two lines set the preprocessor constants. I found that #if DEBUG was no longer taking effect when built using the msbuild line. I think that this is safety protection that DEBUG is stripped when creating a package. I only ever use the package that is created by an automated build system, so it is safe for me to keep the DEBUG constant.
The actual msbuild line has a number of switches. I'll describe the unusual ones:
/p:PostBuildEvent=
If we don't set the postBuildEvent to empty then the same post step will keep getting called forever. And ever...
/p:VisualStudioVersion=11.0
Those clever guys at Microsoft made it possible to open projects with both Visual Studio 2010 and 2012. Which is great, but can bring great sadness when you run msbuild from the command line and end up with nasty MSB4019 error messages because it is looking in the wrong Visual Studio folder for the Azure tools.
Also, note that that I use the cloud profile. Since I am only after the csx files it doesn't seem to make a difference whether I use local or cloud at this point. When I run in azure I specify ServiceConfiguration.Local.cscfg.
Edit: In the end I took this out of the post step and put in my automated build. My original intention was that running the tests from my dev machine would be the same as my automated build, but the post step took too long and the views were sourced from the obj folder rather than the proj folder when running under the debugger which meant I had to copy across when making changes on the fly.
Unanswered questions
It would still be good to understand how msbuild does things to reduce knowledge friction when dabbling in this area. Does it create a package for the website and pass it to CSPack? Or does it parse the project files and then pass some crazy arguments to CSPack? Also when you run an azure project in the debugger, it runs in the emulator with only the binaries in the csx folder (not the images, etc). How does it do that? It would be great to see some description with pictures of the Azure build pipeline with that showed the lifecycle all the way to deployment. That might also explain why there are two copies of the binaries. Also, this would have been a whole lot easier if Visual studio had a project flag like packageOnBuild for the Azure project with options to do a copyOnly or to create a package. I see no point in uneaten cake. Edit: There is a DeployOnBuild setting that can be added to csproj.
Finally, as I mentioned the whole purpose of this is to get a csx folder that I can point the emulator at so that I can run my unit tests on my dev machine. I do the formal packaging on a build machine so don't really need it in Visual Studio. So, really I don't want to package anything and was hoping that there was an easier way of achieving all this.
Since msbuild uses the the azure project file to perform the build, it can derive a lot of information form the project file.
For cspack, the assumption is the role code has been compiled and is available for packaging. Since cspack does not depend upon project file, it needs a explicit information for the code path of the the web\workerrole project. The csdef file does not contain any such information. I suggest if you want to use cspack. Look at its documentation and try to create a package for emulator deployment from command line (CopyOnly option). Once you find the correct syntax you can embed it in you build script.
Using a InstallScript C# .Net Wizard to connect to a WinForms solution where I used the dependency scanner to identify project outputs.
The install package is copying the un-merged app.config file to the target directory instead of the solutions merged MyApp.exe.config file. This results in a executable that does not properly pickup configuration file settings not only because the file isn't named correctly but it also does not merge in target environment settings (ie. release, debug, etc.).
How do you have the Installer copy the merged MyApp.exe.config file to the Install Directory?
Try this, I believe this should work.
Select the config file, and in the Copy to Output Directory under File.Properties, choose Copy always or Copy if newer. You can choose any file you like with this method. Basically this file will be placed to a directory where the binaries are built. This is still a better method than configuring/fixing from InstallShield, I think. I will like to hear from you, if you disagree.
Another thing, a config file is used and determined at run-time by code. That’s probably the reason why InstallShield does not know the file dependency on it. And it is out of scope for that tool.
Have fun and let me know what happens.
Tommy Kwee
I am using SlowCheetah to do my app.config transforms and here is what we're doing to get installshield to work. For postbuild step, copy all files needed by installshield to a separate Install folder (i.e. copy "$(ProjectDir)$(OutDir)." "$(ProjectDir)bin\Install"). Point installshield to that folder to build it's output
I'm also using SlowCheetah for my config transforms, but the real answer to this question is that the InstallShield project pays attention to the selected Solution Configuration. If you select the Release configuration before building the InstallShield project, the Release output will be used in the install package.