i created a setup application for a windows forms application, i changed th "Default Location" property to [D][GestionStock][GestionStock] in order to install the application in this directory and i set "AlwayCreate" property to true.
but this doesn't create the custom folders and install the application directly in "D" drive.
How to set installation path to a custom folder like [D][CustomFolder][CustomFolder] and create folders during the installation?
It looks as if you are inventing property names that don't exist, such as D and GestionStock in square brackets. The brackets mean that they are Windows Installer properties, either standard or created by something in your setup. So D is not a property name, and neither is GestionStock.
These are the standard properties:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa370905(v=vs.85).aspx
So if you want a folder with GestionStock in the name, just use it without the brackets. This might also be useful because it describes how to construct folder locations using strings and properties:
https://www.red-gate.com/simple-talk/dotnet/visual-studio/getting-started-with-setup-projects/
such as [ProgramFilesFolder][Manufacturer]\NewSetup where the bracketed names are property names.
The main problems you have are:
Setups are expected to install to standard folder location property names such as [ProgramFilesFolder], [CommonFilesFolder] and so on because they work on all systems. In your case your setup is assuming that all systems have a D: drive, which they don't. If you want to try installing to the D: drive, just try D:\Gestion\Gestion if that is the location, forgetting brackets.
There is a browse dialog that users expect so that they can choose the installation location, not you.
Windows really wants you to install your binaries to ProgramFiles, for the app and the install to store data in AppDataFolder (the Windows Installer property name) and so on. Going against this model will make your setup more difficult.
1.Type REGISTRY EDITOR in the search bar and click on it. It will as for permission click on YES.
2.Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion
3.Follow the above path.
4.Change ProgramFilesDir path to D:\Program Files
5.Change ProgramFilesDir(x86) path to D:\Program Files(x86)
And you're good to go. The default installation directory is changed from C:\ to D:\ in your WINDOWS.
Related
I have a Visual Studio installer that installs a Windows Service hosting a Web Service.
What I am trying to resolve is to give users during installation a choice of where a particular script is located on the box and once they have set the location to then update the location to the app.config file which the application can then use.
At the moment during install I have added a custom folder and added to that the folder the file. This all gets installed. I want to keep this as a default, but to be able to overwrite it with the users new choice.
I have added a user interface and a text box to capture the user's choice, and a installer class, but this is failing when I try it. Where it is failing is when it is try to find my App.Config file. It says that it cannot find it. In my code, I have written:
string path = Assembly.GetExecutingAssembly().Location;
So, to me my app.config has not been installed into this location when the installation is running at that moment in time.
So, can someone please advise how I can override and save the new location.
Thanks
What you're doing won't work for a number of reasons.
Custom actions in VS setup projects run after all the files have been installed, so it's too late to choose a folder where files can be installed. UI is supposed to be at the front where the normal wizard UI forms run, but VS setups don't support custom dialogs.
Installer classes with UI tend to do strange things because they are called from the execute sequence in the MSI, and the apartment threading won't work.
You're not running in an interactive user environment. Your installer class is being called from an msiexec process running with the system context. If you need to load files, name the path explicitly.
If you're going to stick with Visual Studio setups, your best bet is to install the script to a normal default location and have your app offer a way to copy it somewhere. Then the user can copy it somewhere new whenever they want and you're running in a normal user environment.
You can not get the directory full path where the MSI is being installed using,
string path = Assembly.GetExecutingAssembly().Location;
above code will probably return a path C:\Windows\System32 which has the msiexec.exe location which handles the MSI installation. Use the following code within installer class to get the installation path.
string installationPath = Context.Parameters["assemblypath"];
Rest of your questions are not clear.
Folks
Managed to resolve this myself.
I added an afterinstall event to the Installer class. In this event I added this line of code
string assembley = Assembly.GetExecutingAssembly().CodeBase;
UriBuilder uri = new UriBuilder(assembley);
string path = Uri.UnescapeDataString(uri.Path);
string directory = Path.GetDirectoryName(path);
To get the config file - I did this
Configuration config = ConfigurationManager.OpenExeConfiguration(Assembly.GetAssembly(typeof(ProjectInstaller)).Location);
This gives me what I want and it works
It's more "architecture" then "language" question.
I have a class library in my .Net solution, that generates something using images from a directory that is deployed with the application. User has to be able add new images easily, so I can't put them to resources.
This directory is attached to this class library. Is there any way to get its path? AppDomain.CurrentDomain.BaseDirectory for debug returns /bin/debug/, that isn't right of course.
i.e. - my application is installed to C:\Program Files\MyApp. So, path has to be "C:\Program Files\MyApp\ImagesLib".
BUT:
my application is downloaded from subversion and saved to d:\my projects\MyApp. So, path has to be "d:\My Projects\MyApp\ImagesLib".
How to make this path universal? The directory is created from Visual Studio (right click/Add/New Folder)
I think your architecture needs a rethink.
In the new UAC world you're expected to write to specific locations on a per user or per computer basis. If you install to Program Files for example, under UAC trying to write to your install folder may fail (depending on privileges).
Because of this you will need to use Environment.GetSpecialFolder() coupled with the SpecialFolder enum.
You can read more about these here:
http://msdn.microsoft.com/en-us/library/14tx8hby.aspx
http://msdn.microsoft.com/en-us/library/system.environment.specialfolder.aspx
For example, assuming you just want to store on a per computer basis:
var base_data_folder = Environment.GetSpecialFolder(SpecialFolder.CommonApplicationData);
var data_folder = Path.Combine(base_data_folder,"MyApplication");
var images_folder = Path.Combine(data_folder,"Images");
On my Windows 7 machine this would equate to:
C:\ProgramData\MyApplication\Images
I am developing deployment project for Vista. In Vista inside AppData folder there are Local, LocalLow and Roaming folders. What I want from installer is to create folder 'Data' inside LocalLow folder and put there file data.xml (AppData\LocalLow\Data\data.xml). Installer should make this operation for all existing user accounts.
How can I achieve this?
This is a screenshot of setup project('Data' folder configuration) which is not working:
Attached example creates the following path: \AppData\Roaming\LocalLow\Data\data.xml
I think a much better approach is to store the xml file in the application's install directory, then, when the application starts up, copy the file to the appropriate directory.
The primary issue is this: what if a user that wasn't on the machine when it was installed launches the application?
Since your installer didn't copy the file to their directory (because it didn't exist), your application would either have to do something or fail anyway.
For testing and debugging purposes, I just hard-coded the file paths for the text files that would be used by my application, e.g.
const string CONFIG_FILE_PATH = #"C:\myconfigfile.txt";
But I don't think it's a good idea to leave it as it is in the Beta/Release version.
So I am wondering, what would be the best location for saving these configuration files that will be used / read by the application? Any suggestions?
Many Thanks.
Why not save the strings in the Settings section of your project? GRight click on your project in Solution Explorer, select Properties, go to the Settings section and add a new string with your file path. Then, in your code, you can access it like this:
using ProjectName.Properties;
var path = Settings.Default.MySetting;
To change the setting:
Settings.Default.MySetting = newPath;
Settings.Default.Save();
In the same folder as the executable.
But you should consider using a Settings class (you can read more here). Visual Studio can automatically create a strongly typed wrapper around a section in the app.config file.
The settings are stored in the same file as the executable, but can be overridden (and saved from the application) in a matching file in the user profile for each user.
Another option: If the test config file is intended to sit along side your executable, you can "Add" "Existing Item..." to your project and then change its properties to "Copy always" or "Copy if newer". During debugging, the executable should be able to find the copy of the config in its current working directory.
This isn't such a useful solution when there's a lot of testing to do.
For settings I would certainly use the app.config file. This is proposed by Microsoft and apart from that it is pretty much the easiest way to handle application settings anyway.
For other files I'd recommend either the applications local or roaming settings path, depending on weather you only need the data local or not. For compact, local databases I tend to use this approach. The application directory, as suggested by Albin, is a bad idea. You cannot be sure that the user is actually allowed to write to that directory and/or files in that directory (i.e. the app was pre-installed by an admin with elevated rights).
To get the location of the local paths use
ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.PerUserRoamingAndLocal)
and for the roaming path
ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.PerUserRoaming)
More information on Windows User Profiles (the actual paths in different versions of Windows for example, you can find here: http://msdn.microsoft.com/en-us/library/aa372123.aspx
In my project I have to create some files and directories into my app folder which is into program files. But in vista it is giving me error that I dont have access to create file.
What should I do now for giving access ? Also it not let me access the registry !!
The program folder is not the place to store application data. There is an %APPDATA% folder for that - you are supposed to store your data there.
Use System.Environment.SpecialFolder and System.Environment.GetFolderPath to obtain the path leading to the correct directory.
Also, you need to differentiate between just creating a folder and putting some files in there (for example during installation) or writing to the program folder at runtime, while typically running under a limited account.
The reason for this difference is simply that installation routines and setups run with elevated privileges under Vista / Windows 7, thus those are allowed to create folders and files there. Still, those files are not supposed to be written to at runtime of your application.
So, what is it you want to do? Write data at runtime, or put some files (i.e. dependencies) in your application folder at a single time? If it's the first, comply with the rules and use the %APPDATA% folder. If it's the second, create an installer / setup routine.
Vista and Win 7 have the Program Files folder locked down so you can't write to it with a basic user account. If you need to create folders there, then you should do it in the installer. Otherwise you can use the user's Application Data folder in their profile.
The only other way is to modify the permissions on the installation folder at install time.
Can you turn the UAC off? Or Login as administrator? The chances are that you are creating the folder in the wrong place.