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
Related
I have some confusion about Windows path (dev machine) and Linux path (target OS for microservice)
I created a new folder in my c# project (app/yamls), put inside a file aaa.yaml and put the file in git ignore. On my windows dev machine, I see the file in c:\myproject\app\yamls. However, my microservice will run on Linux and aaa.yaml file will reside in /app/yamls.
When I run the following, I get file is missing
string file = "/app/yamls/aaa.yaml";
System.IO.File.Exists(file) // FALSE
What should be done so the new added file in visual studio will be seen as file residing in /app/yamls like it will be in production.
Thanks
You need to code file and directory handling in a cross platform manner.
You could something like this: https://learn.microsoft.com/en-us/dotnet/api/System.IO.Path.PathSeparator?view=net-5.0&viewFallbackFrom=netcore-5.0
That System.IO.Path.PathSeparator will be / on Linux and \ on Windows
What I usually do is create an appsettings.json file with file location in there. And then change the config file depending on where it's deployed (Linux or Windows)
Path class has static members useful if manipulation of file paths required in .Net environment. Look at these:
Path.DirectorySeparatorChar
Path.AltDirectorySeparatorChar
Path.PathSeparator
Path.VolumeSeparatorChar
If you just need to create path from given components the Path.Combine(...) method is also useful.
I'm making the GUI program that users can decompile/recompile an APK file but compiling won't work correctly becuase the framework file is missing. I'm making the simple framework installer that must be installed on user folder (for apktool.jar). Instead using the path that only works on my computer. i want to make it work for all users.
here is the code i made
File.Copy(#"do-not-touch\1.apk", #"C:\Users\quoc\apktool\framework\1.apk");
You can use the Environment.SpecialFolder Enumeration to get the path like so:
var userDir = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
Note: Please use ApplicationData and not the root profile, it's rude to fill the user's toplevel profile with stuff.
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
I have a default application setup created using Visual Studio 2005. When my application is installed, it's only work running as administrator, because some files are written in the Application Folder.
I have found that on Visual Studio 2010 there is a property for change this permission on some folders inside application folder.
How can I allow to my application create and edit specific files inside the application folder without run it as admin?
Here are your options, assuming that you cannot change where the application itself attempts to read/write files:
Change the default installation directory of the installer of the application, to not go inside C:\ProgramFiles, but instead to a folder just off the C:\ drive that has more lax access permissions. This was standard practice in Windows 3.1 and even Windows 95, but these days you can't get a program "certified" by Microsoft as compatible with any supported Windows version unless it installs into the proper Program Files directory. These modern OSes also have the root of the C:\ drive locked down pretty tight so you'd need administrative permissions to install the app (but not to run it).
Create a custom action for the installer which increases the access rights of the program subfolder during installation. Again, Microsoft is unlikely to certify the app if you do this, and this also requires admin permissions to install the app, meaning the average user on your network can't just pull it down and run it.
Install the files that must be altered in the "proper" places (Application Data for user-specific files, Program Data for files pertaining to the software as a whole), and then create shortcuts within the main application folder that point to the files in their accessible locations. The legacy app shouldn't know the difference.
EDIT: Here's a method straight out of the custom actions of the installer for an app I wrote that has a similar "legacy" app, which has to read/write data from config files in a subfolder of the app's "home" directory. The IDictionary passed in is the one you get from the various custom action methods (OnBeforeInstall, OnAfterInstall, OnCommit, etc), so you simply drop this into an Installer class, call it from the handler for the install event of your choice (which must be after the installer has made the file system changes), and call it:
private void SetEditablePermissionOnConfigFilesFolder(IDictionary savedState)
{
if (!Context.Parameters.ContainsKey("installpath")) return;
//Get the "home" directory of the application
var path = Path.GetFullPath(Context.Parameters["installpath"]);
//in my case the necessary files are under a ConfigFiles folder;
//you can do something similar with individual files
path = Path.Combine(path, "ConfigFiles");
var dirInfo = new DirectoryInfo(path);
var accessControl = dirInfo.GetAccessControl();
//Give every user of the local machine rights to modify all files
//and subfolders in the directory
var userGroup = new NTAccount("BUILTIN\\Users");
var userIdentityReference = userGroup.Translate(typeof(SecurityIdentifier));
accessControl.SetAccessRule(
new FileSystemAccessRule(userIdentityReference,
FileSystemRights.Modify,
InheritanceFlags.ObjectInherit
| InheritanceFlags.ContainerInherit,
PropagationFlags.None,
AccessControlType.Allow));
//Commit the changes.
dirInfo.SetAccessControl(accessControl);
}
You could manually change the NTFS folder permissions using Windows Explorer to the Application Folder. However, it would be best practice to read/write to a different folder.
Don't write anything to the application folder (under program files). Instead use the user's home folder, or, if you want to write something that's relevant to all users on the machine - ProgramData.
EDIT:
If you can't change your application code, you should still avoid placing program data files under ProgramFiles if you can. There's one other thing you can do. You can create a folder under c:\ProgramData, and just create a symbolic link to it from C:\Program Files... . That way, your legacy application still finds the data where it expects to find it.
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.