I installed an MSI buillder tool on my visual studio 2017 and started deploying my desktop application with generated MSIs. The istaller is able to copy vital files and adds registery keys but it does not copy some additional config files which are required for logger. According to this page, switching "Copy to Output Directory Property" to "Copy always" supposed to take care the issue however, it still does not copy the config file into output directory on client's computer.
Can somebody give an advice about how I can diagnose this problem ?
Edit:
I think I can explicitly add logs files into MSI with following method but I have two concerns on this. Would I add the file into MSI with its global or relative path ? Secondly will it be a good practice ?
Edit 2:
For the reference for developers who has the same issue, looks like the method stated above adds files with its relative path. I added screenshot of difference page at source control.
It is completely normal to add individual files to a VS setup project. Every tool that generates an MSI works this way. VS setups are probably the exception with their "project output" type of input choice, where you get little idea of the actual files that will be installed. So you get the best control of the MSI content by adding each file individually, including that config file. Also, some files really don't belong in the Application Folder (that defaults to Program Files) because they are data files that belong somewhere like the User's Application Data.
The path where the MSI build gets its files from is nothing to do with where that file is deployed on the target system. You tell the MSI build where files will be deployed on the target system by using the File System view on target machine, where you get a list of destination folders to add files to.
Also, the copy to output directory stuff is nothing to do with the build of the MSI file. As far as I know, its main reason is to allow you to have all dependencies at the output build location of the code so that the program will work correctly from that location, and it happens to give you the opportunity to get all the files going into a setup from the same place. It does not mean "copy this file somewhere in such a way that it is automatically included in the MSI build and the deployed on the target system".
Once you get the MSI working and installing the config file, you may run into Windows Installer file overwrite rules that prevent you from overwriting files that have been updated after they were installed.
Related
Say I use some .json files to descript some object data which effect to the program's behavior, I hope to use these files in the following scenarios
The default values, for this purpose, I need a set of files follows with the application to be packed and installed.
I wish it could be edited by human manually. (Because something have no interface to be modify on UI)
Both user and the program need to kwnow the location the files will be placed after installation.
In debugging stage, I could put these files in the user\AppData\Local.. folder and I know how to access them, but I don't know how to put files into the package and will them generated to anywhere after install?
Thank you for any suggestion.
ps.
I use the "Blank App (WinUI 3 in UWP)" template to create my
application.
I'm new in UWP and WinUI, I used to write traditional Windows Form programs.
How to include externel user files into UWP side-loading package?
You could place the json file into app's project and set the file property as Content, then it will deploy into installtion folder after package install. and please note the json file is readonly in the installtion folder.
so you could call CopyAsync method copy the file to the destination folder that app's local folder with full permission.
For more details about file access permissions please refer this document.
I use NSIS to create an installer for my project. Wishing to have as small a filesize as I can, I began looking into my project's dlls, included files and prerequesites and noticed the following are all different:
the minimal files required to run, as determined by educated guess + trial and error. I made sure the application works properly with this minmal set of files.
the files exported by the "Publish" fonction for click once deployment (excluding click once specific files)
the files in the release directory (excluding the pdb and vshost files)
It seems VS2015 generates an xml file for every dll. Some dlls I don't use and don't reference are copied as well.
My question is why is there so many unnecessary files and how can I configure VS2015 to not have them in /release?
If you set VS build log level to verbose you will see exactly what happends during build and why a file goes to release folder. Once you determine the reason, you may either change your project file to adjust predefined behavior or add post-build event to remove unwanted files produced by build process.
MSBuild file, located at "C:\Program Files (x86)\MSBuild\12.0\Bin\Microsoft.Common.targets" is very useful to dig into build process details as well.
However, if you indend to distribute the content of release folder to other machines I'd suggest you look at some installation software, like Wix, for example. Once you create a setup project which includes files you do want, there will be no need to fight for release folder content.
I recently took charge of a new system, it is a windows application written in C#, an installer (.MSI) file is created for its distribution. When I install the software it installs properly but it crashes on start. Then if I run the .exe file once for the application, the installed software starts working.
My observation is that .EXE installs some missing bit which is required by .MSI file. Is there a way I can find what files are missing in .MSI file ?
UPDATE on 09-08-2014:
I have found WER4A29.tmp.WERInternalMetadata.xml file which talks about System.Net.WebException
-<ProblemSignatures>
<EventType>CLR20r3</EventType>
<Parameter0>test.exe</Parameter0>
<Parameter1>1.0.3.33</Parameter1>
<Parameter2>53dca4f6</Parameter2>
<Parameter3>System</Parameter3>
<Parameter4>4.0.30319.18408</Parameter4>
<Parameter5>52311185</Parameter5>
<Parameter6>21b0</Parameter6>
<Parameter7>1fb</Parameter7>
<Parameter8>System.Net.WebException</Parameter8>
</ProblemSignatures>
First run an admin install via command line (cmd.exe) to extract the files from your MSI:
msiexec /a File.msi
Then inspect the extracted files to determine if there are configuration EXE files that perform configuration tasks. Determine what configuration files are there, if any. For example INI or XML files. Check for per user / user profile files.
In case you don't have the tool to view the MSI file, get hold of Orca or install a trial version of a commercial packaging tool. You will need this to see what is happening inside the MSI file. If you list the content of the Custom Action table there may be clues there as to what is going on. Also look in the Registry table for per user data to go into the registry. Debugging an MSI properly takes a lot of domain knowledge, but looking through it like this is useful too. Just post follow-up questions. I assume you have the Wix source code too?
To debug the application launch use Process Monitor (procmon.exe) to determine what is going on during the successful launch. The logging is a bit verbose, but with flags you will get to narrow it down.
- For native applications (Win32, or non-.net), I like to use Dependency Walker (depends.exe) too. It can be used for .NET too, but I find it less useful. I am not aware what the best dependency scanner for .NET is at the moment.
If manual debugging fails, several tools used for application repackaging are able to scan the system and determine the state before and after something is done and capture it as a list of differences. Advanced Installer's trial version should be able to do this. With some technical insight you should be able to identify what is needed from the diff image.
The .msi file is the installation set-up it include the installation script and the actual executable .exe file and other required dlls and configuration files.
I think the issue is with how the set-up is created. when you start the application after installation it is not performing the start up tasks like configuration of environment.
And the when you run the .exe it takes care of these configruations by it self.
I suggest that the testing of setup files .msi files and its generation scripts should be revisited.
Everything in Visual Studio seems to lead one to putting data files with the application.The app.config goes there, when I create an .XML data file, there is a Copy to Output property that will automatically copy that file to the exe folder. Howerver, it seems that under Vista and Win7 UAC doesn't want the application to be able to write data to any file in the application directory. So I'm changing my evil ways so that I use the LocalApplicationData folder for files I want to read and write. (I just read the app.config so I'm leaving it alone)
I'm using a VS2010 Visual Studio Installer project to create the installer for this app and I can't seem to find a way to target the folder for my .xml file to the LocalApplicationData folder. I can click on the file and see a Folder property but the dialog only has options for Application Folder, User's Desktop and User's Program Menu. Is there some way to do this in the installer or do I have to write code that checks for the file and copies it over from the .exe folder when it doesn't exist? I figure I'm late to this particular party and there must be a canonical way of handling this.
Also, I'm wondering about debugging, is there something similar to the copy if newer functionality in the build process that will now copy this .xml file automatically over to the LocalApplicationData folder whenever I update it?
The Setup project doesn't expose LocalApplicationData in the Special Folders list. You can use it anyway by doing this:
Add a Custom Folder and set the DefaultLocation property to [LocalAppDataFolder]
How do I specify Default Location of where my Product is to be installed and create additional folders for Log Files, Temporary Files?
For instance, if I decide to install every instance of my application in the path
C:\Documents and Settings\\Application Data\ is where I want to install my Application, that is, the DLL's, Executables all need to be there.
C:\Documents and Settings\\Application Data\\LogFiles is where I want to write the Log Files.
C:\Documents and Settings\\Application Data\\Temporary Files is where I want to write the Temporary Files that my program will generate (and delete thereafter)
So, I want my Setup to create the main folder and the sub-folders.
In addition, I want to write my AppName.exe.config in a way, that it points to the above created sub-folders.
How do I achieve the same.
My Environment Details:
Visual Studio 2008
C#
These are not appropriate paths. Your app needs to go into c:\program files\manufacturer\productname. Your temporary files need to go into Path.GetTempPath so that they'll get cleaned-up when your app crashes and forgets to clean up the temporary files. Find the directory at runtime. Your log files need to go into c:\documents and settings\username\application data\ folder. Find the directory at runtime with Environment.GetFolderPath(). Don't store paths in app.exe.config
This ensures your app will install and run on any Windows version.