Is there any possible way of moving the runtimes and *.exe.WebView2 folders created by the Microsoft WebView2 WPF package to a different folder or perhaps embedding them?
The 2 folders are selected in the screenshot below.
I already use Costura.Fody to embed dlls. The ideal result would be if those 2 folders would be moved to the bin folder.
You have to fix both folder issues separately
The *.exe.WebView2 is a cache folder created when you run the webview2 inside the application. The following is how to redirect the folder to where you want it it to go, I used Path.GetTempPath().
CoreWebView2Environment cwv2Environment = await CoreWebView2Environment.CreateAsync(null, Path.GetTempPath(), new CoreWebView2EnvironmentOptions());
await webBrowser.EnsureCoreWebView2Async(cwv2Environment);
Path.GetTempPath() will redirect to the users local app data temp so it would prevent permission issues on the servers and be easily maintained by infrastructure on growing hard drive space.
A current temp solution is move the runtimes folder to the home directory if that is where you want it and the second line deletes it. In Visual Studio go to the project properties -> Compile -> Build Events and in the Post-build event command line and added the following.
xcopy /y $(TargetDir)runtimes\win-x64\native\WebView2Loader.dll $(TargetDir)$(OutDir)
RD /S /Q "$(TargetDir)runtimes\"
The .\{ExecutableName}.WebView2 folder is the default location of the user data folder. This contains all state generated by the WebView2 (cookies, HTTP cache, indexeddb storage, and so on) and by default is placed in the same folder as the host app's executable. But you can (and should) specify a different path to store the user's WebView2 state. For more information about the user data folder and where to place it see the Manage user data folders doc.
The second folder .\runtimes contains the WebView2Loader.dll file in different CPU architectures. There's currently no way to specify the path to find this but that has been requested (GH issue) and is in our backlog.
Related
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.).
A C# executable can reside in 3 different locations during it's life cycle when going from development to end user distribution:
{project directory}\bin\Debug
{project directory}\bin\Release
{end user install directory}
My app has a web page and some ancillary files that I like to put in a sub-directory called \video, right beneath the directory that contains the executable. What I really don't want to do is copy the sub-directory around between the 3 directories listed above. In other words, obviously I don't want to end up with:
{project directory}\bin\Debug\video
{project directory}\bin\Release\video
{end user install directory}\video
with the inherent re-copying every time the file in \video change.
What is a convenient overall strategy for keeping data files distributed with an application in a centralized directory, a directory that will be added to the setup program when the application is distributed? I'm hoping that I don't have to add build tasks to copy over the data files to the \Debug and \Release sub-directories every time the application is run in the Visual Studio 2012 IDE. That leads to potential errors if I forget to copy a file during the build tasks and can create a mess if there a lot of files, especially large ones.
Is there a way to build the top level data path that detects conveniently each of the 3 different runtime contexts? I don't mind if I have to wrap all relative data paths with a method that canonicalizes the data path when a relative path is passed to another method. Here's an example using a fictitious method named fixRelPath() that would expand a relative path properly before passing it to a sample method named openFile():
openFile(fixRelPath(".\\video\\temp.html"));
You should put your files in the AppData directory.
Per User:
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);
Shared:
Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData);
I'm developing a Web application that uses a couple XML files to store data. I have their Build Action set to Content, and on install the files are copied successfully to the Applications Virtual Directory:
C:\inetpub\wwwroot\ApplicationName\
The problem I'm having is that writing to these XML files (in order to save settings and things like that) causes a lot of write permissions issues. Therefore to get around it, I'm trying to copy these files from the virtual directory they're installed to to a new directory under the C drive, using the following PostBuildEvent in the Web Deployment Project:
xcopy "$(TargetDir)*.xml" "C:\CompanyName\ApplicationName\" /y
However, this does nothing. I'm not sure if this is because PostBuildEvents in the installer are not actually fired on install, but only on building the installer, or if TargetDir represents the bin directory:
C:\inetpub\wwwroot\ApplicationName\bin\
instead of the root application virtual directory:
C:\inetpub\wwwroot\ApplicationName\
Does anyone have any ideas? Has anyone dealt with this sort of thing before? I'm really stumped on this one.
Update:
I included a PostBuildEvent that should give full permissions to all users:
icacls "$(TargetDir)" /grant Users:F
But it doesn't seem to have resolved the problem.
I'm also unsure where exactly $(TargetDir) if pointing to, if it would be ..\ApplicationName\ or ..\ApplicationName\bin\
All you have to do is give full permissions to the user under whose context the Web Application Pool runs.
You can find this user by starting IIS manager and look at the Application Pools and Identity column
Something like
cacls C:\inetpub\wwwroot\ApplicationName /G Users:F
will give all permissions to this subdirectory to all users on the computer, If you are running under ApplicationPoolIndentity refer here
Turns out there's a much easier way to do what I was trying to do.
Instead of using PostBuildEvents to create a new directory structure and move files there, I added the new directory structure into
InstallerProject > View > File System
after which I located the Content Files from SomeProject entry in my installer project, and changed the Folder value to the newly specified directory structure, in this case
C:\CompanyName\ApplicationName\
This seems to work fine, I'm now able to access these files freely as I originally intended.
I have built a C#.NET WinForms App. I now need to build a MSI installer for the same so that I can ship it to my clients.
I am stuck at the following place.
I use log4net for Logging. How do I write my App.Config in such a way that the LogFile folder is based on where my end user installs the Application. That is, if my end user installs it on the Default Location of C:\Program Files\\, then the LogFile folder will be C:\Program Files\\*LogFiles*.
If they chose to install it elsewhere, the LogFiles folder will be a sub-folder of the MyApp folder.
Similarly, I have a TemporaryFiles Folder where I store the temporary files while I am modifying the original files. This again should be a sub-folder of the MyApp Folder.
I also understand that the Application Folder points to the [ProgramFilesFolder][Manufacturer][ProductName], where does the CommonFiles folder point to? And typically what goes inside that?
I use VS2008 for Building the Setup.
I would simply not have the log files in the program files folder. The process needs write permissions on it and generally you would only want administrators to have write permissions on the program files folder or any of its subfolders. I would rather consider using e.g. %appdata%/yourapplication/logfiles. Then you could easily have your log4net config point to that location, regardless of where this will be set up. I would do the same thing for the temporary files.
(I don't have an answer to that CommonFiles question.)
I have a simple C# console application developed on my local machine using VS2008 Pro. I want to know how to deploy this solution onto a network share folder?
A similar Java console program is already placed (as a JAR file) in the same network share folder. Users simply open command prompt, navigate to shared folder and type "java -jar programName.jar inputParameter1 inputParameter2"
How can I achieve the same with .NET?
You can copy the exe over yourself, go to the bin folder in the directory your source code is in and copy it there.
or you can click the BUILD menu and use the PUBLISH menu item. This will allow you to enter the path to your network share and visual studio will copy the built app to the folder for you.
If your application is really "simple", you should be able to just copy the files to a shared folder and run it from there. However, if your "simple" application tries to do things that are restricted by the permissions you might have to configure them with caspol. Assemblies loaded from a shared drive have much fewer permissions than the ones loaded from a local drive.
It would be mostly the same process as the Java program. To deploy, compile the program and copy the exe from the bin folder (along with any dependencies) to the network share.
To run the program users would open the command prompt, navigate to shared folder, and type "programName.exe inputParameter1 inputParameter2"
You can use Publish feature of VS. Note that you can change settings in the Publish section of the console application project to remove some features that you don't need. For instance the renaming of .dll and .exe files by appending the '.deploy' extension to the name of the files or publishing in a new 'version' folder each time. Go to "Project Properties"->"Publish" and remove "Automatically increment revision" checkbox at "Publish Version", click "Options..." button and clear all checkboxes there too.
Right click your project, select publish which will make an executable, you can put that in your shared drive, similarly users can go into the command prompt and run it and give some args.
In the exact same way assuming they have the proper dependencies installed (.net, 3rd party assemblies, etc). copy the bin folder then have them execute the exe file.
Take a look at ClickOnce deployment:
ClickOnce is a Microsoft technology
for deploying Windows Forms or Windows
Presentation Foundation-based
software, also called Smart clients.
It is similar to Java Web Start for
the Java Platform.
MSDN
Wikipedia