I would like to have App_LocalResources folder outside web application folder, so that I could deploy updated resx files and web app. independent of each other.
Reasons: We do not want to change current deploy tool.
Any way to achieve this?
Way the default resource manager works in asp.net is it picks the resex entries for the respective aspx file from the App_LocalResources folder in the current directory. As far as I know this behavior is not something you can configure (i.e to ask it to pick entries from a different folder!) But there is a workaround, that you could implement your own Resource Manager and let it picks entries from a location you specify it to. Found this and this while googling. Hope that helps.
Related
The app's cache and data directories in MAUI is: C:/Users/{UserName}/AppData/Local/Packages/{GUID}_{hash}/{LocalCache/LoaclState}
When I create a MAUI project, build and run it. A folder will be generated in Packages/ named {GUID}_{hash} like B4B241BA-CD04-4CE4-83ED-FD99159F72A0_9zz4h110yvjzm
I want to find a way to avoid using GUID as the name of a folder. Because it makes it hard for me to discern which folder corresponds to which app.
I have tried to modify the property ApplicationIdGuid in .csproj. But it didn't work at all.
I have found some apps not use GUID as folder name, like Bandisoft.com.15700C60EE320_dytvnjx3s1h08, TelegramMessengerLLP.TelegramDesktop_t4vj0pshhgkwm, so I think there maybe someway to achieve that.
As Jason suggested, you could create a shortcut.
I am trying to help port a .Net service to a more modern .Net version (possibly Core) and use the MSIX installer. The application has several configuration files generated by the compiler (in source they are app.config but compiled they become *.exe.xml), they are installed into Program File right next to the binaries and a GUI helper app as well and the application itself can modify them to change service behavior (port, ip, tls cert, etc).
Writes under C:\Program Files\WindowsApps\package_name are not allowed.Writes under C:\Program Files\WindowsApps\package_name are not allowed.
The problem I am facing is that the MSIX installer makes it so that files in it's sandboxed version of Program Files cannot be written to (see above). That means that this application cannot be configured, so I am trying to figure out not only how to make the app configurable again, but also how windows wants to handle app configuration.
Right now it seems like there is two general approaches to do this:
write the configuration data to the service account's AppData/local folder
try to mimic a /etc/Myservice behavior in another folder. (meaning a local system-wide directory that houses configuration data for the service)
If you suggest #1 please answer the following additional questions:
How would I move Application configuration files to a user configuration file directory
how can an admin with a normal account modify the config file in the Service Account's AppData folder with the mentioned GUI helper application? (do they need to enable desktop access to the service account, login and run the GUI)?
If you suggest #2:
Where would you suggest this directory exist (specifically where will MSIX allow it)?
How do I tell the .Net application that the files are not right next to it? Can I just use AppData.CurrentDomain.SetData?
Well, a service running on the system account is the same for all users, so I would say that CommonApplicationData is a better folder for storing its settings, instead of appdata. This folder is easily accessible to both your service and to any admin that needs to deploy a custom config file.
In AppData you should store only actual user files (like files or settings generated by the actions taken inside your app by a specific user - thus different files for different users).
Now, the second part is where you need to configure you code to load the config file from a custom path instead of looking for it next to the EXE. I am no .NET expert but after a quick search I found this:
Relocating app.config file to a custom path
The modern approach to deploying app customizations
What is not clear to me is how your customers use the GUI helper tool to customize the config file. Is this just a tool that is used by someone from the IT department to generate the config file, and then they would copy that file and deploy it to the end-user machines using an MSI/MST file (or through some other custom deployment method)?
If your application is only deployed by IT folks, then you can try another simpler (and much elegant) solution for providing it with a custom config file, which actually doesn't require any code changes.
You can still leave the config file next to the EXE, in ProgramFiles and instruct the IT teams that deploy the app to use an MSIX Modification Package to deploy the custom config file generated by your GUI helper. (check the link included above for an example - with a video version at the end of the article).
Note: IT teams can use multiple free or paid tools to generate MSIX Modifications Packages.
Of course, your GUI helper tool still needs to generate that customized config file in a folder where it is allowed, as it can no longer write under ProgramFiles. So actually, you do need to modify a little bit your code in this scenario too.
I'm trying to get localization to work in my application. I can follow the typical example online and get it to work in a sample project. (ie. setting the Localizable property and the cultures).
When I try to use it in my application, it always uses the default resource file no matter what language I choose.
EDIT: If I go to the properties of my startup project, select Debug, and set the Start Action to Start Project, it will work. If I run the executable that gets created when building by selecting it in "Start external program", it will not work. Any idea why?
EDIT: When I use the Start External Program, the executable I am pointing to is not pointing to the bin/Debug folder of the project. I have a post build event to copy it elsewhere and am pointing to that. Because of this, maybe it is not able to see the reference files that are in the Debug folder?
When you localize a form, it creates a folder per language in the build's output path that holds a resource file projectname.resources.dll.
I have a post build command that puts our .dlls elsewhere. I needed to change the command to also push out the resource files so that they were in the same directory. Once I did this, I was able to get it to work.
I am developing a desktop application using C# winforms. I am creating some files and folders on the directory that my application runs at. I am deploying the application by using the click once approach. My problem is that everytime i update my application it creates a new root folder to run at. And i won't be able to use those files anymore. Any workarounds for that? I am thinkin of creating a folder at "C:\MyCompany\MyApplication" but then it will be easily reachable and breakable. I will be happy to hear any other advises or knowledges that will favor me :)
You should store the files and folders in the user's Application Data folder. You can get the path to this folder with this statement:
string appDataPath = System.Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);
You should then create a folder in that path for your application and store everything there.
There are of course other solutions, but the point is that you should not use the application folder, since this will indeed change everytime you publish, and it is bad practice for several other reasons (data backup, etc.).
I'm planning to build my winform into a .exe file. I'm just wondering what to do with the XML files that my application needs?
I did some research and found out that I can add the XML files in the Resource folder before creating a .exe file.
Or I need to create a setup file? When the user runs the setup file, the XML files will be installed into their pc.Now I wonder which one is the best way to go for,
Note: XML files might get modified by the user.
If you want to ship the XML files as seperate to the .EXE then you can set the Copy to Output Directory to Copy if newer. (click on file and then go to properties).
OR if you want it as part of the .EXE I think you can change the Build Action to Embedded Resource.
I personally would create a Setup as per your edit and include the XML files. I usually just add everthing from the bin/release folder that is needed when I create a setup file.
You could either deploy the necessary files along with the executable in the same folder or embed them as resources (if they are read-only). If you need to modify them do not embed them as resources into the executable.
The correct way depends on how you intend to use the files. If the files always are deployed together with your application, the application never writes to them and they are never upgraded without upgrading the application, you can go with them embedded as resources.
If you need to update them separately from the application, you need to have them as physical files.
You don't necessarely need a installation package, unless you need to apply some logic during setup, such as updating the content of the setup based on user input or to check preconditions. The application can just be copied into place regardless of if you have embedded the files or not.