I've been publishing my game for me and my friend to test and I've started to make a text file in the code to use as an error log but I'm getting some problems and I can't find anything on the internet to help me.
I want it so the user can get the installation files, install it at a custom location, run it through a shortcut and so I can create files where the user installed it for saving the game, an error log and such.
What happens is, I make a clickonce application, but after using the setup.exe the shortcut isn't usable, it just says "program has stopped responding" because it's trying to make a file and I can't run it as administrator. I can only set administrator to the setup.exe, there's just no options for the game's shortcut or any of the clickonce applications. And I have no idea how to let the user choose an installation directory.
I've searched through google and the msdn library but I can't find anything. It says if I don't use clickonce deployment I need another installation package but I can't find anything. I also tried modifying the app.manifest to turn:
<requestedExecutionLevel level="asInvoker" uiAccess="false" />
to
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
but it won't allow me to publish it then because it's a clickonce application and if i turn it off in the security it just turns it back on when i try to publish it. Can someone please tell me my options, I just want a normal game installation like every other game it's driving me nuts I can't find anything.
This is not a direct answer to the question, but it might be what you actually need.
You should be able to create and use files in the ClickOnce applications deployment folder without any security restrictions (no admin rights needed), which you can access with
ApplicationDeployment.CurrentDeployment.DataDirectory
Note that when updating the application all the content in this folder will be rewritten, so you should recreate any log files and such you have.
Edit
Actually, strike that - this msdn article says otherwise: you still need security permissions in order to read and write to this folder.
However, it also says that Isolated Storage is used exactly for this purpose: reading and writing application-specific data in partial trust, such as with un-elevated ClickOnce applications:
Isolated Storage
Isolated Storage provides an API for creating and accessing files by
using a simple API. The actual location of the stored files is hidden
from both the developer and the user.
Isolated Storage works in all versions of the .NET Framework. Isolated
Storage also works in partially trusted applications without the need
for additional permission grants. You should use Isolated Storage if
your application must run in partial trust, but must maintain
application-specific data.
Edit 2
But still, before using isolated storage, try the application deployment directory - it works fine for me!
Related
Access to path denied error is encountered in Program files (x86),
while working with a DLL that is got from nuget package: AODL for reading ODF files - https://www.nuget.org/packages/AODL/ after I created a MSI file using SETUP Project
In the code, I don't suspect the file creation part for I create this file in the user chosen file conversion path but NOT IN PROGRAM FILES folder path:
File.WriteAllText(targetFileName, sb.ToString(), Encoding.UTF8);
That's why I simply suspect the DLL, please let me know how I could find the error and fix this.
A bunch of directories - both Programm Files, the root directory of the System Drive, Windows - are heavily protected by NTFS rights. Writing them is usually a plain "no-go". Unless you run around with full administrative rights - wich only Instalers and very rare Adminsitrative tools should even consider - you will not be able to write there.
However you indicated this happens on a read. Reads being blocked like that is very unusual. You need to check what rights are set on those folders and why. Maybe the installer accidentally copied the rights from your computer, wich only makes sense with your users and groups? Maybe Windows or a third party broke those rights? Not a lot of options I can think of that could apply here.
For this application, even for reading the DLLs from the Program Files folder I needed Admin rights so I forced the application to have such rights for execution.
The below line for the newly created application manifest file is changed and that solved the issue.
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
The fix is explained well in How do I force my .NET application to run as administrator?
The reasons are stated well in https://stackoverflow.com/a/50588465/129130
First off hi all, and thanks for the many times searching here has helped me out or taught me something.
I've made a custom HUD for a game I play, and am working on an installer in C#, inspired by another HUD for the same game. It downloads and overwrites all the script files to the existing directory:
C:\Program Files (x86)\Steam\steamapps\me\team fortress 2\tf
[I don't have any control over which folder to use unfortunately, since I'm modifying files which Valve installed]
In order to delete folders, add folders, or copy files, I've had to use an app manifest to increase the user permissions every time the exe is launched:
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
Somehow, the installer I've been inspired by is installing to the same folder that I am, without forcing a UAC prompt.
His app only shows a security warning, but if I uncheck the "always check" checkbox, I can run it over and over again without having to verify any special permissions:
http://www.trishtech.com/img_art_a/win7_publisher_not_verified_0.jpg>">
Any suggestions on how I can make my app more seamless like his? I've contacted the author of the other app, and he says he is also using C#, but doesn't know of anything special he's doing to make this work.
EDIT: A few things I know we're doing differently, just in case they make a difference somehow:
I'm using a file browser to decide where to put my files, so the app can be run from anywhere.
He's just outputting them to the same directory as the exe, requiring the exe to be put in the destination folder.
I'm using ILMerge to bundle SharpZipLib with my app.
He's just leaving the dll in his zip file next to the exe.
If you are trying to write to "C:\Program Files (x86)" then you need admin rights. It follows that the other app must not be creating files there, but to a directory that is not protected by UAC.
If your files are per user, then you can create a subfolder in the appdata folder and save the files there.
Convention is to create a folder to indentity the company and another to identity the product,
eg
var dir = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
+ "\\MyCompanyName\\MyApplicationName";
He's just outputting them to the same directory as the exe, requiring the exe to be put in the destination folder.
I don't think that will be it. The same exe directory should be no different, you either have permissions or you don't.
The "normal" response would be, write to a directory you have permission to. But this is not always possible.
If you ran your application as a service it would popup just the once I think under Windows, but this does not seem right for your use case.
I don't think there will be any proper way to suppress such a message, its like a catch 22 situation. To do something you cannot do, you need to get permission (so elevate user -> UAC popup).
I'm marking sgmoore's answer as the right one, although my own case seemed to be something a bit stranger and I want to document that too.
I've stripped down my program to the basics and done a lot of experimenting. I figured out that for some reason, he and I actually can copy files and create folders into that directory. Maybe it's something special about the steamapps folder, or maybe it's just a bug that's making it actually work in this limited case, when it shouldn't normally for "real" programs.
What was actually requires the UAC prompt, strangely, was running the exe from the \Bin\Debug\ folder where my project was initially generating it. If I move my exe somewhere else and then run it, it works fine. If I run his exe from my \Bin\Debug\ folder, his doesn't work either. I haven't been able to figure out why that is.
Something else I noticed is that when my app is going to succeed without an exception, it doesn't prompt with the security warning when I launch it. It just silently opens and then works. Any time it does display the security warning, it fails.
I guess the protocol would be to turn those two issues into new questions, but it seems at this point it's probably well into edgecase/hack territory since all of you agree that this shouldn't even be working at all.
I'm going to build my program back out and see if I can still get it to work with full functionality under these weird circumstances, or whether I'll have to reenable the UAC elevation.
I have an Application in WinForms,
I have created SetupDevelopment project and then install an application using Setup.exe file
i have added MSAcceess db file into application folder file,
when i install an application the database file gets readonly. how can i make file writtable after installation?
I found some solution on internet and found that when i tried to install application in different path other than "C:\ProgramFile\" and make application available to all user,it solves my Problem, but i want to install an application only in "C:\ProgramFile\" and want to available to only "Current user"
how can i achieve my Problem ?
In modern Windows Operating System the folders 'Program Files' or 'Program Files (x86)' are read only for the common users. This choice has been done for security reasons and you cannot easily bypass this rule. The reccomended folders, to use just for the current user, are C:\users\username\AppData\Roaming or C:\users\username\AppData\Local identified by the Environment.SpecialFolder.ApplicationData or Environment.SpecialFolder.LocalApplicationData. To this base folders add another subfolder identifying your application or company and install your database there.
If you want your database available to all users of the current PC, you could install it in the Environment.SpecialFolder.CommonApplicationData that resolves to C:\programdata. (Again, adding a subfolder specific for your application or company)
Again, don't try to force the operating system to work against its rules. You will find yourself in trouble very often.
We have an application that was built for the Windows Mobile and Windows platforms, using Visual Studio 2005. We have both versions of this application developed using a single code base to try and reduce code duplication. One of the issues that we encountered with this was that the ConfigurationManager was not available for the Windows Mobile platform. We worked around this by building our own ConfigurationManager that reads and writes settings to the "Application.exe.config" file in the Program Files folder. So both our Windows version and our Windows Mobile version use this same custom ConfigurationManager.
This worked fine on Windows XP and Windows Server 2003, but on Windows 7 we have encountered a problem and I don't know how to work around it. When we make a change to the config file (which we can only do by copying it to another folder, changing it and then copying it back... otherwise we get an "access denied" message when we try to save our changes directly in the Program Files folder), the change that we make is only reflected if we run the application as Administrator. If we run the application as a normal user, the default setting from the install are always shown. We suspect that this is a Windows 7 security-related issue, but can someone explain why this is happening? How can we change the settings so that they are also applied when the application is run as an ordinary user?
Windows 7 requires elevated privileges for several folders, including program files. It's not good practice to try to work around this.
Since you are using a custom solution, one option is placing your configuration file under %APPDATA%\yourproduct, which can be reached with
var appDataFolder = Path.Combine(Environment.SpecialFolder.ApplicationData, product);
A better solution is probably to use different configuration managers for different platforms, though. Couldn't some kind of abstract factory be applied?
I suspect your app tried to write to the config file at least once running non elevated and without a manifest. This made a "compatibility files" folder for your config file. When you run non elevated it looks there now. (See http://www.gregcons.com/KateBlog/FindingFilesYoureSureYouWrote.aspx for screenshots of how you can confirm this.)
If all you want is for a human, or some utility program you wrote that can run elevated, to be able to edit the config file, you can leave it where it is and put a manifest on your app to prevent virtualization. See http://www.gregcons.com/KateBlog/AddingAManifestToAVistaApplication.aspx for a sample manifest. That blog post goes on to tell you how to embed the manifest, but you don't need to, an external manifest will work. If your app is foo.exe, name the manifest foo.exe.manifest and put it in the same folder. This will prevent virtualization and cause the app to read the "real" config file.
If changing the config file will be a normal everyday occurrence, don't write the file under Program Files. AppData is a good choice.
I have created a windows application setup program, it needs to have a text file in the application folder. The file is also included while creating the setup.
Once the setup successfully completes and my program tries to modify the file based on user input, its simple throwing an exception.
I am using Windows 7 Home Premium OS.
Any suggestion/help will be great to overcome this issue.
This is normal on a Vista or Win7 machine. Or a properly secured XP machine for that matter. The normal install location for programs, like c:\program files\your company\your app, is read only for most users. UAC is a counter-measure to malware messing with programs.
You'll need to store the text file into a writable location, the AppData folder. In the Setup project, right-click "File system on target machine" and select User's Application Data Folder. Find that file back at runtime through Environment.GetFolderPath, passing Environment.SpecialFolder.ApplicationData. Or use "User's Personal Data Folder" if the user should be able to find it back easily through the Documents folder.
What exception is being thrown? It could be a UAC issue.