When I build my .NET Core 2.0 console app, I move it over to the server and I then try and run it. I am getting the error "An assembly specified in the application dependencies manifest..."
I add the dlls to the local folder that it is searching for, but it ends up still needing system dlls like Data.SqlClient.
How do I build the project where it includes all the dependencies in the output files? I've published the project with Visual Studio 2017, however, it still says things are missing when I copy all those files over. I've tried building and publishing with VSCode and have the same problem.
I faced a similar problem. When I deployed my application in host environment and executed with dotnet command like "dotnet myapp.dll" it worked fine using the host environment's .NET Core runtime.
But when I packaged the same application as a Standalone application with an .exe file included to start the application, I faced this error for Newtonsoft.json Nuget Package when .exe file is executed.
My observation is as below, and I was able to solve the problem accordingly.
Framework-dependent deployment:
If the application uses third-party libraries and intention is to use the .NET Core runtime in the host environment, then the checkbox in the "Manage Packages for Solution" has to be checked in the Nuget Package Manager (as shown in the screenshot).
Self-contained deployment:
If the published application is supposed to be a stand alone application in the host environment (even with an .exe file), then the application's .csproj file should include the RuntimeIdentifiers (.NET Core RIDs) specified. Also the third party libraries have to be included in PackageReference. For example,
Reference: https://learn.microsoft.com/en-us/dotnet/core/deploying/deploy-with-vs
You need to publish the application to have all the dependencies included
Related
After I included some .cs files from another project in my application when I publish my app and run it I get the following error.
My application is a windows form and the files I included are some kind of file parser in order to process a certain file type.
I have tried many times to rebuild and reload the project but the result is still the same. The target framework is .NET 4.8.
Does anybody has any idea on how to solve this issue?
That's because most probably, the code you inserted requires the presence of that dependency.
However, System.Memory is not part of the default framework, it's current version is 4.5.4 and it can be found on nuget.
If you use Visual Studio, you can conveniently add it to your Solution by using the Nuget Package Manager
You need to handle that dependency, either by installing the nuget package for your solution, or by directly downloading and providing the dll and its dependencies from the nuget site (not recommended).
I published my program(.net core 3.1 winform program). but it doesnt excuted even installed .net core 3.1 run-time package. so i install .net core 3.1 sdk package, it works.
why i install sdk instead of run-time package?
The software development kit (SDK) includes everything you need to build and run . NET Core applications, using command line tools and any editor (including Visual Studio). The runtime includes just the resources required to run existing
There was a problem creating a single file by using app.config in the wrong way.
When app.config was used in the correct way, it was confirmed that it works normally only with the runtime sdk.
Previously, both *.dll.config and *.dll were required, but after correcting it, only *.dll.config worked normally.
I create a new C# project WPF Application - A project for a .NET Core WPF Application.
Framework: .NET Core 3.1.
Project loaded. (you have an empty form)
Right click on your project and check that you have "Output type" Windows application. (It means when you click on build it creates an EXE file in BIN folder of your project)
Then add a new project to the solution : Setup Wizard by extension Microsoft Visual Studio Installer Projects. Then follow steps as is here -> https://stackoverflow.com/a/6090929/15917420
In the end it packages DLL into installator file instead EXE.
So if you take setup.exe and install it, it installs DLL.
Do you have same problem or am I missing something?
If I create WPF with .NET Framework I dont have this problem.
Thank you
EDIT: recorded video: https://drive.google.com/file/d/11ElC0F62klxQOI-beOn6LhcZbyOb7QDT/view?usp=sharing
I had the same issue. Microsoft has published this:
https://learn.microsoft.com/en-us/visualstudio/deployment/installer-projects-net-core?view=vs-2019
Basically is says that for .NET Core projects, you have to use the "published items" instead of "primary output" when building the setup project. It also has a couple of other hints too.
When targetting .NET Core, the "main" project (the one that is the application) gets two files, a dll and an exe file. The exe file is only a stub loader that locates the dotnet runtime and transfers control to the corresponding dll. Simply put, the exe of a .NET core project is executing the dotnet <dll-with-the-same-name>-command.
With this in mind, you need to make sure that your installer installs both the dll and the exe (and any other similarly named files, such as <Application>.deps.json).
Im just trying to run a DotNet Core console app on a Windows Server 2012 R2 but I keep getting this error:
Error:
An assembly specified in the application dependencies manifest (Application.deps.json) was not found:
package: 'Microsoft.Web.Administration', version: '11.1.0'
path: 'lib/netstandard1.5/Microsoft.Web.Administration.dll'
The dll that is missing is inside the /publish folder...
I used Dotnet publish with the correct Runtime Identifier (win81-x64)
I installed the Dotnet runtime 2.0.7 on the server
Always use the publish output when deploying to a target sever.
It can be found in
bin\Release\netcoreapp2.0\win81-x64\publish
in your case (self-contained application)
or in
bin\Release\netcoreapp2.0\publish
for framework-dependent deployments.
The output in the directories above are meant to be used in development only, since they are specific to machine and user configuration built with.
I had this issue because I deployed the wrong publish folder.
I decided to take the time a setup a publish profile.
In solution Explorer...Right Click on the Project -> Publish
or from the menu Build->Publish
.NET Core application publishing overview
Using a publish profile you can set the target location to something simple
drive:\Publish\[project]
This will save you from haveing to navigate 10 levels deep an possibly copying the wrong folder.
Deploy .NET Core apps with Visual Studio
In .NET framework, you can make a single .EXE file that will run from the command line without having any extra config files (and if using ILMerge, you can put all .DLL references into the 1 .EXE assembly).
I am taking a stab at using .NET Core to accomplish the same thing, but so far without success. Even the simplest Hello World application with no dependencies requires there to be a file named <MyApp>.runtimeconfig.json in order to run using dotnet.exe.
dotnet F:\temp\MyApp.dll
The contents of the <MyApp>.runtimeconfig.json are as follows:
{
"runtimeOptions": {
"framework": {
"name": "Microsoft.NETCore.App",
"version": "1.1.1"
}
}
}
Without this config file in the same folder as the .DLL, I get the following error:
A fatal error was encountered. The library 'hostpolicy.dll' required to
execute the application was not found in 'F:\temp'.
My question is: Is there some way to change the application so it doesn't require this config file to be present, so that the defaults of this information are compiled within the .DLL but can be overridden by adding the config file?
NOTE: I also want to ensure it "just works" regardless of the platform it is installed on it provided the platform has the right version of .NET Core.
Background
I am trying to get a smooth user experience for running some utilities that are useful sometimes, but are rarely ever needed. Since it doesn't appear to be possible to use the same .DLL that is referenced from a client application as a console application, the next best thing would be to have a single file that could be downloaded and run without any dependencies.
For example, in Java you can simply download a .jar file on any supported platform and run:
java <package>.jar <namespace>.SomeClass [args]
and it will "just work" without any extra files. How can I get a similar user experience using .NET Core?
In a nutshell, I want to try to avoid the extra step of "unzip to a directory first"...
Update 2018: .NET Core 3.0 aims to enable a new scenario: packing the .NET Core runtime and all application dependencies into a single executable.
At the moment, there are no fail-safe methods to create a single executable file. Since there are a lot of type-forwarding dll files involved, even ILMerge and similar tools might not produce correct results (though this might improve, the problem is that those scenarios haven't undergone extensive testing, esp. in production applications)
There are currently two ways to deploy a .NET Core application:
As a "portable application" / "framework-dependent application", requiring a dotnet executable and installed framework on the target machine. Here, the XYZ.runtimeconfig.json is used to determine the framework version to use and also specifies runtime parameters. This deployment model allows running the same code on various platforms (windows, linux, mac)
As a "self-contained application": Here the entire runtime is included in the published output and an executable is generated (e.g. yourapp.exe). This output is specific to a platform (set via a runtime identifier) and can only be run on the targeted operating system. However, the produced executable is only a small shim that boots the runtime and loads the app's main dll file. This also allows an XYZ.runtimeconfig.json to set additional runtime properties like garbage collection settings.(think of it as a "new" app.config file)
In the future, the CoreRT runtime – which is still under development at the time of writing – aims to allow creating a single pre-compiled native executable that is specific to a runtime and does not require any other files.
Tested with .NET Core 2.2 on a console app:
Reference Microsoft.DotNet.ILCompiler package in your output project. You'll need to add MyGet package repository in Visual Studio settings. *
Publish the project via command line,
dotnet publish C:\src\App\App.csproj -c release -r win-x64 -o output-win-x64. If there's no "Desktop Development for C++" component installed, do it in Visual Studio Installer, or the command will fail.
Go to the output folder (e.g. "C:\src\App\output-win-x64") and grab the native image (.exe file).
On Windows it produced a fully functional 5Mb .exe file (compared to original self-contained publish with folder size at ~60Mb). On macOS the ILComplier though produced output without any error, the app crashed with unhandled expection (on the line with LINQ expression).
*Go to "Tools -> Options -> Package Manager -> Package Sources" and add new source at https://dotnet.myget.org/F/dotnet-core/api/v3/index.json
It is possible in .NET Core 3.0+
The feature is enabled by the usage of the following property in your project file (.csproj):
<PropertyGroup>
<PublishSingleFile>true</PublishSingleFile>
</PropertyGroup>
There are other options as well, such as packaging the pdb into the bundle, or leaving certain files out.
Documentation can be found here: https://learn.microsoft.com/en-us/dotnet/core/deploying/#publish-self-contained
True it just works:
Combine this technique with the Self Contained Deployment workflow, you can get a true "it just works" experience for your user, they don't even have to install the .NET Core runtime for your app to run.
I am currently deploying applications to my clients as single .exe files.
Read more about that here: https://learn.microsoft.com/en-us/dotnet/core/deploying/#self-contained-deployments-scd