Thank you Gerry Schmitz,
i can able to update the version in assemblyinfo.cs but my issue is i don't know how to get all assemblyinfo file path(ex: in my solution i have 5 projects i need to update all assemblyinfo respectively) from solution file.
I know why I am having the problem but I need a solution/workaround.
I have a c# program that generates excel output and saves it as an html file in the user's document folder. This automatically generates the [excel_file_name]_files subfolderwhich is used to store specific info used by the html file. The program ALSO auto-generates jpg images every time it is run based on historic data that is taken from the spreadsheet each time it is run and saves those images in this sub-folder. The program needs to be able to delete the files it creates within this folder but of course the user's folder makes sure to keep programs from simply deleting arbitrary files within the user's folder so that prevents me from deleting them as I do not have permission to delete a users files.
Is it possible for me to programmatically grant the application OS permissions to delete/change files it creates within a user's subfolder? Or will the user need to run the program with admin rights each time (if they can even get such rights).?
Did you read my post? I already specified that. Specifically the program saves an Excel file "as an html file in the user's document folder. This automatically generates the [excel_file_name]_files subfolder... The program ALSO auto-generates jpg images every time... and saves those images in this sub-folder."
If that is too confusing, it is a subfolder of %USERPROFILE%\Documents created by Excel. This is BEFORE the application exports any excel files to html so the folder is not in use... and my application checks to make sure the folder exists before attempting any file operations; just in case the user has not ever used the program before.
Regardless, the enumeration resolves to a location determined by the .NET implementation for the specific OS. I am using the enumeration by default so whatever that returns is what I am using. The user has the option to change this but it doesn't matter in context as user specific considerations would not be an issue in a custom folder unless those permissions are altered to something other than the default (which is beyond my control).
It is an app run by the user that ls logged in. IT seems to be working now but it crashed previously. From my experience, applications have their own permission sets. Are you saying this is not the case? I have had several experiences that would suggest otherwise; the latest being that on Windows 10 a downloaded Excel document opened by the user in excel will allow itself to be read because I have overridden the default behavior. However, if the user launches my application to do the same thing, it will crash with a COM error that appears to be related to the fact that downloaded files are not allowed to be read under the current permissions. This is unique to Windows 10 as it does not happen under Windows 7. I had to import a non-COM Excel reader when I ported to Windows 10 in order to get it to read excel files without crashing (or without me personally opening the files myself in debug mode).
From my experience, applications have their own permission sets. Are you saying this is not the case?
Correct. Applications ALWAYS run as the user the launched them, inheriting the security token (permissions) of the user. There is no way to get around this.
Applications also cannot grant themselves permissions over and above what they inherited from launch. That was be a massive security risk. Windows, and every other O/S with security built into it, simply does not allow that to happen.
The sole exception of this is when running under Vista and above, an administrator user account can be split into two security contexts, the normal user version of the account and the administrator version. Normally, everything runs as the normal user account, unless admin permissions are required. That's when User Account Control comes in and asks if you really want to run something as an administrator, or if you explicitly launch the process "as administrator".
Ok. I am following you. I realize that permissions inherited from the user make sense. However, having an application run with fewer permissions than the user is not a safety hazard in terms of security and my experience is that this can happen.
Another example (which is incidentally timely, and appropriate for this thread) is that permissions are an issue with certain virtual system accounts on which older versions of this program run. (The creation and deleting of jpgs is a new, unreleased, feature). I have isolated the old issue to something in the way permissions are granted to newer versus older users. The following code causes the application to crash for newer users only. The folder being searched (directoryInfo) is the Downloads folder for the user:
FileInfo fileInfos = directoryInfo.GetFiles("GeniusExport*.*", SearchOption.TopDirectoryOnly); // CAUSES CRASH ON VM
For all users, the user profile directory is a mapped drive. Perhaps directoryInfo resolves to something non-existent for newer users and perhaps I should test that; however this is a Windows 10 environment. I know for a fact that the people I have worked with who have this problem have a Downloads folder that is being used.
This isn't a permissions problem in the normal sense. That little line of code works on every machine and VM I have, under every account I normally use.
This is something unique to your environment. Perhaps a problem caused by antivirus or some other security software software.
I'm working with large antivirus vendor right now on a problem that causes Excel to crash on first start after a certain app is installed, which is just a add-in for Excel. Disabling the antivirus doesn't fix the problem. Stopping every single process in the antivirus or uninstalling it completely fixes the problem.