My friend showed me on his pc, how to execute code, without using visual studio. He opened the file location of the project -> bin -> Debug -> netcoreapp3.1. Then he copied the application file and pasted it on his Desktop. Then he double-clicked it and the application opened. I was really impressed. I tried to do the same, but it wasn't working... and I have no idea why. Here is the video of me trying to do exactly what he did:
video: https://www.youtube.com/watch?v=xejkdqwwScs
If you are trying to execute a C# application, it is likely that you need to ensure that the necessary DLLs are in the same directory as the application executable. DLLs are libraries of code that the application needs in order to run properly. Without the appropriate DLLs, the application may not run or may not run correctly. To make sure the necessary DLLs are in the same directory as the application. Once you have identified the necessary DLLs, you can copy them into the same directory as the application executable. This should allow the application to run correctly.
Related
I am entangled in how to work so that after I finish building the wpf app, I can give it to another computer by downloading the app (for example, downloading the .exe file). I also tried it, but when I ran the .exe file, it only showed a popup cmd and then disappeared. Then I have pulish with self-contanied deployment mode. Here is an image of the following files when I published at bin\release:
Path: C:\Users\ASUS\Source\Repos\UserService\WpfApp1\bin\Release\netcoreapp3.0\publish
If I run the .exe file in a folder then run normally. But when I copy it to a deskop and run it is still the same (can't run).
I want to ask how can I help my app to be used by other computers. Thank you mn! Forget more, my app is using .net core 3.0 already.
I have an application written in C# using VisualStudio 2015 and I want to publish it (eg give an exe or installer to somebody to use it on its PC). From VisualStudio there is possibility to click "publish" in solution explorer. The result files are:
-Application files (File folder)
-project.application (Application manifest)
-setup.exe (Application)
As far as I know "manifest" file should be some metadata, but I can execute that file and it gives me an installer (the same as setup.exe). After installing it runs an application (just like setup.exe). It makes me confused - what exactly project.application is? Can I delete it and use only setup.exe? What is the correct way of publishing an app? One last thing: why does the installer run installation on first execution and run an application on any other? I would expect to run installation any time (just like other software).
Thanks
It sounds like a ClickOnce application. See the following link for more information:
ClickOnce security and deployment
In a nutshell:
The installer copies the files to the users AppData and then runs the application.
There are also other options such as checking for updates from a network location or web address. Then when you run the application it checks for updates and uses the manifest to do an incremental update of the application files.
I'm fairly new to windows forms and I was recently tasked with creating a simple software which will be deployed by USB drives to other companies. I made this software so during first run I check for a config.xml file. If it doesn't exist, I will send the user to a form to configure their first time setup. Next time I run the program, it skips this step since the config.xml file is found with its values. The problem is when I debugged this, I found the config.xml file alongside the executable, however when I ran this on a different computer, it stored it into the appdata virtual store. I read up on this and found out it has to do with write permissions.
Is there any way I can get around this without prompting the user to do anything extra on their part such as run as administrator? I also plan on saving the resulting reports generated by the use of this program and was hoping I can have XML files which can be easily found within the application folder.
*Note, I am aware of the built-in settings system but this also stores into appdata and if the executable is moved to another directly, it loses sight of that config and wants to create another.
EDIT : Please be aware I am trying to AVOID writing to the AppData folder. The software is packaged with Visual Studio Installer - Setup Project. A msi file is created which stores the application in C:\Program Files (x86)\\. Inside this directory I have the executable, the exe.config file which is generated, and any DLLs needed. This is the folder I am trying to also store the config.xml file but due to some windows magic, the code thinks its storing it here but in reality it is being stored in the virtualStore folder located in AppData.
Have you thought of using the C:\ most computers have this unlocked. alternitively use Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);
the AppData folder is stored in the username space and requires no permission. (just remember to create a folder for your program to avoid conflicts)
It is a known issue due to security concerns that write permissions are limited.
More can be learned here.
Since no one was able to answer this, I will post my solution. Instead of packaging the solution using Visual Studio Installer tools. I install the application by copying the resulting executable from the build. This version of the application has write permissions that would have not existed if the application was installed using the resulting .msi from the Installer tools.
I am using Visual Studio 2010 and I'm writing in C# (console program). I used to output a standalone .exe file from the debug folder (just copying the single .exe file to the client computers).
Now, it happens that different clients needs a different connection string. My solution was to copy the .exe file and also the .exe.config file from the debug folder. Modifying the config file will then directs the program to use different connection strings.
The concern is:
How about the other files in the debug folder, should I be copying them to the client computer as well? (e.g. .exe.manifest or .vhost files? )
Or shall I release the program into click-once file and install them into the client? But it would be quite troublesome and time consuming to install and uninstall the program on many computers (during version upgrade), also more complicated to call the program from bat files?
I used to just use the .exe file from the debug folder. But when I found out that the .exe actually reads from the .exe.config, I wonder sole use in the .exe would result in leaks in the program?
I have created a simple inventory application in WPF. How should I give it to client now ?
One way what I did: I have set my AppPresentation solution as start up project and I can see all the DLLs from other solutions are added in the Debug and Release directory of this solution.
When I copy the Release folder to other drive (from D: to C:) and run the AppPresentation.exe some Error occurs about some DLL missing but I can still see those DLLs in this folder.
However when I copy the debug folder to the other drive and run the application i.e. AppPresentation.exe now I can run the application successfully with complete working.
Can I give this entire Debug folder to the client and expect that it runs perfectly on his machine ? I will ensure .NET 4.0 Framework is installed on that machine (but not Visual Studio ofcourse). Will this work ?
It will work as long as you have the required version of the .NET Framework installed on the client and all the necessary dll's have been included,
Ideally you should look at creating a Visual Studio setup project:
Using a setup project has the following advantages:
All your dll's and other files required for the application to run will be consolidated in one setup file
You can specify prerequsites such as .NET Framework which will prevent installation until all the required components have been installed first.
Users can specify exactly where on disk the application should be installed without manually copying the dlls (as would be the case in your scenario).
This is but a few advantages of using a setup project but hopefully you'll be convinced to give it a try as it is the preferred way of installing Windows applications
P.S If your setup project gets more complex consider looking at Wix