androidi said:
figuerres said:
*snip*

The app I made needs to know where the file is and modify it even when putting in a hdd from another computer. So if I put in a system hdd from another computer it would be quite crappy to start figuring out where the file might be without access to environment variables etc. An ok compromise would be if I could elevate the program when needed at runtime instead of doing that on every run. I agree on your other points however that still leaves the question why the Demand/Assert gave no errors.

 

re: Guidelines. Just following the same guideline as Microsoft when throwing these files in C:\ Smiley

 

dd_depcheckdotnetfx30.txt
dd_dotnetfx3error.txt
dd_dotnetfx3install.txt
dd_vcredistMSI782E.txt
dd_vcredistUI782E.txt
dd_VC_i64RuntimeMSI27F6.txt
dd_VC_i64RuntimeUI27F6.txt
dd_VC_x64RuntimeMSI27EF.txt
dd_VC_x64RuntimeUI27EF.txt
dd_VC_x86RuntimeMSI27E6.txt
dd_VC_x86RuntimeUI27E6.txt

Whilst I 100% agree with everyone elses comments that it's the wrong place to put files and you absolutely should be using the correct location (for one thing, you app is going to break with Fast User Switching and numerous other scenarios), let's look beyond that and see what the problem is.

 

In this case, I suspect it's the low level code for FileStream.Open and I don't think it's going to be easily worked around whilst continuing to write to the root of the drive, as it would imply it's caused by the permissions on C:\ itself and that's not something you want to try changing. The quickest solution at this point is to put a folder in the root of C:\ and then store your file inside it. That should get your app working again with the minimum amount of effort.