C# .NET 6.0 WinForms x64bit Desktop application
Application exe runs fine via the project's "x64\Release" folder.
We deliver via an MSI created via "Setup and Deployment Tool". When the application is installed via the MSI file, the user gets an exception as the application launches.
System.PlatformNotSupportedException: System.Management currently is only supported for Windows desktop applications.
at System.Management.ManagementBaseObject..ctor(SerializationInfo inf, StreamingContext context)
I've tracked this down to a difference in the file: MyApp.deps.json between the "Release" folder and the installed destination "Program Files" folder.
If I copy that "Release" .json file to the "Program Files..." location, the application runs fine.
What's going on with the Setup and Deployment MSI creator? How can I fix this?
Runtime Configuration Files:
MyApp.deps.json - A list of dependencies, compilation dependencies and version information used to address assembly conflicts. Not technically required, but required to use the servicing or package cache/shared package install features, and to assist during roll-forward scenarios to select the newest version of any assembly that exists more than once in the application and framework(s). If the file is not present, all assemblies in the current folder are used instead.
So you'd better have it deployed with your application.
Regarding the issue. Do you use publish profile? Please check if you specified it in PublishProfilePath, as described in Visual Studio Installer Projects Extension and .NET 6.0
Also you can check what do you have in you publish folder and try to configure the publish profile to have everything you need there.
Related
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.
Have I an application using sqlite...
Ive tried this:
installing via ClickOnce Application setup (it works)
I Put SQLite.dll file together with .exe in the same folder. (it works}
hmm the folder with an .exe only (not working)
What I mean is when you build the project and get the .exe on the folder \bin\Debug and move it somewhere then when you run the app errors will not occurs.
I wondering if there's a way that i can run even without installing ClickOnce Application setup?
I thinking of setup the SQLite.dll on specific path reference? Is it possible to do that?
-thanks
System.Data.SQLite.dll is not part of the standard .NET Framework so it does not get installed in the GAC of the client machines when .NET runtime is installed at first.
that's the reason why you should have this dll referenced by your executable, distributed together and in the same folder as your exe is deployed.
or you could distribute it somewhere else like in a sub-folder of your application setup and have proper entries in the configuration file or in the .NET C# code to specify where assemblies not found in the standard locations have to be loaded from.
You can use Nuget to get the package installed. For my case, it automatically created 2 subfolders for me, which is x86 and x64, I just followed the folder structure in the bin folder, and it worked fine for my case.
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
I have created a windows application and I have published it by publishing wizard.
Now I want to make it portable so that the end user does not need to install the application.
The application is very simple and the only dll it is referencing is office outlook interop.
Please let me know how can I make the application portable
You should be able to just copy the files in the bin folder and launch the app from there. This is called "XCOPY deployment", long marketed as one of the major benefits of .NET applications.
Just make sure that you set the properties on the Office reference so that the DLL is copied into the bin folder, too.
However, for this to work, the client machine must have the appropriate version of the .NET Framework installed. So it won't be truly portable unless you can control the configuration of all target machines, but at least it's a good start.
There's no need for the Winforms application to be installed. Just set Copy Local to true for your external referenced dlls. Build your project and copy all the files in /Bin/Release or /Bin/Debug (depending on project settings).
The only thing that has to be installed on the client's machine is the appropriate .Net Framework version.
I have created a setup for my windows application in .NET 2008
After building the same i have the .msi and setup.exe files in my release folder.
The problem i am facing is :
I can install the application using the msi installer files from the shared network folder. But when i copy the installer locally and tried to install it,
i get the following error: Error reading file.Please Try again.
Anybody having any ideas if there are any properties to set in the installer project.
Regards
Constant Learner
Just a thought, you can use Orca to go through the .msi and see if you're having any static references to your development machine within your msi.
The application is a simple windows application without any database associated with it.
Its just a hello world windows application. So i presume its something related to the configuration part of the installation...
Constant Learner