I have written a Visual Basic.Net application in Visual Studio 2012 Ultimate. When this application is installed to the Program Files folder, when files are saved, they are located in this location:
C:\Users\[Username]\AppData\Local\VirtualStore\Program Files\[Company Name]\\[Application Name]
How can I specify to save the files in the following directory:
C:\Users\[Username]\AppData\[Company Name]\\[Application Name]
folder (basically, not the VirtualStore folder)?
Do I need to register this application within Windows to do this?
Thanks in advance
First, what instalation software are you using?
Second, if you're going to save your app files in the AppData directory, then you should really choose to save your app in either the, Roaming, Local, or LowLocal directory. It isn't "proper" to start making new directories where other directories are available to use, especially since the Roaming, Local, and LowLocal directories were more-or-less made to hold application's data (which is why the parent directory is call "AppData").
Related
The project setting Debugging / Working Directory in Visual Studio 20015 will be saved by default in the *.user file wich I don't check in in to my repo because it's user specific. Still, I would like to have something other than $(ProjectDir) standing there when I do a clean checkout of my project. Is there an other place to store the Working Directory besides the *.user file?
Edit 1: The original idea is that I have a solution with multiple projects and all the binaries (dlls and exes) created end up in a folder called bin. If I want to debug it, I don't want to always edit the working directory again after a clean checkout.
Edit 2: In a post build step of every project within my solution, I copy the binaries in to the bin folder. If I start one of the executables from within VS, it starts them from the $(ProjectDir) folder, and of course not from the bin folder. This is why it does not find the dlls and why I want to set the working directory. I could change the output directory of my projects but then I get a lot of files ending up in the bin folder I don't want there. I will try it anyway; maybe I missed something. To be continued...
Edit 3: As expected, if I change the output directory to the bin folder, everything works fine except for some extra files that end up there and I don't want that (e.g. *.pbo, which would be okay, *.iobj, *.ipdb, etc.) Maybe that is the price I have to pay, but I don't like it.
So, the question remains: How can I have more control over which file ends up where after a build and still be able to run it from VS without changing the working dir?
The working directory should not have to be the directory that contains your DLLs. In fact, you definitely don't want that to be a requirement for running your application. Not only is it a hugely unexpected failure mode, but it could also be a potential security risk.
Put the required DLLs in the same directory as your application's executable. That's the first place that the loader will look. If necessary, use a post-build event in your library projects to copy them there.
Well since no body can help me I decided that I will change the output directory to the bin folder so VS will start my applications from the correct folder.
And how I can get rid of all the extra files that don't belong there I will find a way later.
In a Visual Studio (2013) Deployment Project, I have a resource file (a text-file called settings.cfg) that shall be copied to the application folder. The ReadOnly-Property of that file is set to False.
After installation on the target platform (Win 7 Pro), the file is present (in the application folder), but the file may not be modified by a user without Admin-Rights, it is read-only.
Obviously in the windows-explorer you can modify the access options in the properties dialog, but you need admin rights + time/effort.
Is there a way to allow modification of the file by any user right from Visual Studio?
Editorial answer: Don't install files in the Program Files folder if you want limited users to be able to update them. There are folders like User's Application Data Folder that are actually for the user's data.
The practical answer is that there is nothing built in to Visual Studio setups to do this, so that means writing custom action code to change the access rights. That's really a "how do I change access rights on a file" question rather than a question on setup projects. I suspect the code and setup changes to move that file to a location where it just works might be easier.
Lots of examples of custom actions here:
https://www.google.com/?gws_rd=ssl#q=visual+studio+custom+action+walkthrough
and this should help too:
https://www.simple-talk.com/dotnet/visual-studio/visual-studio-setup---projects-and-custom-actions/
I have a program and a windows service located in the same folder. They could be run under different user accounts. Will they be always able to write to the folder where their .exe are located or this still depends on the rights of a particular account they run under? If not then what folder can I use for sharing common data amoung them?
No. In general, executables are installed in \Program Files\ (CSIDL_PROGRAM_FILES). You need a program-specific subdirectory under CSIDL_COMMON_APPDATA. (Create this subdirectory with appropriate ACL's for your situation).
In most cases (i.e. for most kinds of accounts which are not Administrators) the application (or the service) won't be able to write to \Program Files folder if it has been installed there (as it's done by default).
To share the data between applications you can use FOLDERID_ProgramData folder and get it's path using SHGetFolderPath.
The default installation location of our applications is c:\Program Files folder. Due to virtulization, this is not a good location to install our applications in 'Program Files' folder in Windows 7. What is the preferred default installation location in Windows 7..
Does microsoft say specify anything on this?
Where can I get more information on this?
Our application can create projects which are kept in c:\Program Files\PolyCd\Projects folder. User can copy these files to other machines to use the project files. We also don't want to run the application as administrator to avoid prompting whenever the application starts. This enables virtualizations. And hence the user won't be able to see the project files he created in c:\Program Files\PolyCd\Projects folder
I have one more question. What is the preferred location of keeping the application specific data such as the project information I mentioned earlier
Ah, thanks for the clarification. Your problem is where you are storing the data. Generally, settings and the likes should be stored in the folder specified by the environment variable AppData. Project data, documents, etc however should generally be stored in the user's "Documents" folder.
'Program Files' or 'Program Files (x86)' for 32-bit software on 64-bit Windows. But you would usually use a variable like $PROGRAMFILES so Windows finds the folder itself.
Since you asked specifically "does Microsoft say anything on this?" let me show you the Windows logo requirements from Microsoft. After you download that document, you can read guidance that includes what folder to install to (Program Files) and where to keep the user's data and settings (ProgramData or AppData). If you follow these guidelines, not only will your application behave as users expect, you will find it easy to get the Windows Logo for your application, which is a shortcut into the partner program. Many of my clients save tends of thousands of dollars on software by being in the partner program, so don't dismiss the value of the logo. But the immediate value to you is clear direction about where to put your app and where to put the user's data.
If I use the publish feature in VS2008 (I think it's called ClickOnce install), and then install the published application in another computer, where are the files copied?
In other words: If I need an auxiliary file (a .txt file) in the same path of the assembly, where do I have to create it?
Thank you.
You should have specified the location when you published the application. Just note down that folder.
If you run the wizard again for the same project it should have remembered the location and the folder will be pre-filled on the form.
I've used this and I specified a location on my hard drive for the Publishing Folder Location. This folder contains the following files:
publish.htm
setup.exe
[application].application
It also contains a folder called Application Files which contains the files needed to build the installation - the exe, the manifest, other dlls and external resources.
I then copy the three files and the folder to the web location specified by the Installation Folder URL.
If you're talking about where the files get installed to then they're in:
C:\Documents and Settings\[user]\Local Settings\Apps\2.0\H165QZM1.QBE\0OAEZTRX.Y3N\[some truncated version of the exe name followed by a GUID]
Which isn't the most obvious place. I should also point out that the folders H165QZM1.QBE and 0OAEZTRX.Y3N will probably be different on different machines, but the only other folder under C:\Documents and Settings\[user]\Local Settings\Apps\2.0 is called Data so they should be easy to spot.
Is the application available offline or online only? My experience is online only and in that case I believe it installs into a temp directory. Can you include your auxiliary file as part of the application files? This may help as well it talks about including data files which can be of any type.
http://msdn.microsoft.com/en-us/library/d8saf4wy.aspx
http://msdn.microsoft.com/en-us/library/6fehc36e.aspx