For the last couple of days, I've been trying to compile my .NET Core console application, and upload it to a VPS running "Windows Server 2012 R2". The reason I am using .NET Core is because this is needed for the library - Discord.Net 1.0.
The first thing I tried was simply taking my release DLL file and data, with the following file structure:
LeveledStudios.deps
LeveledStudios.dll
LeveledStudios.pdb
LeveledStudios.runtimeconfig.dev
LeveledStdios.runtimeconfig
This worked fine for execution on the PC I developed it on, however I then went into my server, ran "dotnet LeveledStudios.dll", and was faced with the error
Error: assembly specified in the dependencies manifest was not found -- package: 'discord.net.commands', version '1.0.0-rc-00546', path: 'lib/netstandard1.3/Discord.Net.Commands.dll`
Noticing this fitted the structure of the .nuget folder on my development PC. I copied it across and faced the same issue, and tried to copy it into the same folder as leveledstudios.dll, only to run into some .dll's which refused to work. This also included missing system DLL files, like System.Net.Http, etc.
I did some googling, and saw information about self contained .NET Core applications. This sounds perfect because clearly my problem was that it was not compiling with all my additional libraries. I was a little confused because I did not have a project.json file, as mentioned in all the documentation I read on it.
However when running:
dotnet restore
dotnet build -r win10-x64
I get a host of errors, suggesting none of the system libraries are compiled:
Errors
The contents of LeveledStudios.csproj:
<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp1.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<Compile Include="**\*.cs" />
<EmbeddedResource Include="**\*.resx" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="Discord.Net" Version="1.0.0-rc-00546" />
<PackageReference Include="Discord.Net.Commands" Version="1.0.0-rc-00546" />
<PackageReference Include="Discord.Net.Core" Version="1.0.0-rc-00546" />
<PackageReference Include="Discord.Net.WebSocket" Version="1.0.0-rc-00546" />
<PackageReference Include="Microsoft.NETCore.App" Version="1.0.1" />
<PackageReference Include="Newtonsoft.Json" Version="9.0.2-beta2" />
</ItemGroup>
</Project>
How can I fix this?
...self contained .NET Core applications [sound] perfect... however... I get a host of errors, suggesting none of the system libraries are compiled.
To resolve the errors that happened when you built as a self-contained application, add this one line to your *.csproj file:
<RuntimeIdentifiers>win10-x64</RuntimeIdentifiers>
Restore will then bring down the runtime, allowing you to build and publish as a self-contained application.
dotnet restore
dotnet build -r win10-x64
dotnet publish -c release -r win10-x64
The final *.csproj file looks like this:
<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0">
<PropertyGroup>
<OutputType>exe</OutputType>
<TargetFramework>netcoreapp1.0</TargetFramework>
<RuntimeIdentifiers>win10-x64</RuntimeIdentifiers>
</PropertyGroup>
<ItemGroup>
<Compile Include="**\*.cs" />
<EmbeddedResource Include="**\*.resx" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="Discord.Net" Version="1.0.0-rc-00546" />
<PackageReference Include="Discord.Net.Commands" Version="1.0.0-rc-00546" />
<PackageReference Include="Discord.Net.Core" Version="1.0.0-rc-00546" />
<PackageReference Include="Discord.Net.WebSocket" Version="1.0.0-rc-00546" />
<PackageReference Include="Microsoft.NETCore.App" Version="1.0.1" />
<PackageReference Include="Newtonsoft.Json" Version="9.0.2-beta2" />
</ItemGroup>
</Project>
That's how to publish as a self-contained application, which is one alternative to resolve your initial problem.
The other alternative (which Ryan suggested and which you said did not work) is to use a framework-dependent application, in which case you do not need the RuntimeIdentifiers property. You can then run the same commands but without specifying the runtime.
dotnet restore
dotnet build
dotnet publish
The publish files, which will include the Discord dependencies, will be here:
bin\Debug\netcoreapp1.0\publish
Related
In my VS 2022 solution I have two projects, a roslyn generator and a console app that I use to test the generator and other stuff.
Whenever I try to build the test app I get this warning:
CS8784: Generator 'Generator' failed to initialize. It will not contribute to the output and compilation errors may occur as a result. Exception was of type 'FileNotFoundException' with message 'Could not load file or assembly 'Microsoft.SqlServer.ConnectionInfo, Version=16.200.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The system cannot find the file specified.'
So it seems that I'm missing an assembly.
But actually Microsoft.SqlServer.ConnectionInfo.dll is present in my nuget package directory (under .nuget\packages\microsoft.sqlserver.sqlmanagementobjects\161.47021.0\lib\netstandard2.0, netcoreapp3.1 and net462) and has the right version for all three frameworks.
I also tried to reference assembly path in visual studio, and it didn't give a different result.
Whatever program is running the generator don't seem to be able to resolve it.
Moreover, my test app references the exact the exact same packages and run without any problem.
My guess is that running the generator manually (with my own entrypoint) would allow me to see where it tries to find the assemblies, but I have no idea how to do that with a generator.
Also one of the package gives me this warning for the generator but not the test app:
NU1701: Package 'Microsoft.SqlServer.Management.SmoMetadataProvider 161.47021.0' was restored using '.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project.
I would like to know how I can make my generator work, or at least, have some way to debug it to get more information on why it fails to load the assembly.
Here are the .csproj for the generator:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<Nullable>enable</Nullable>
<EmitCompilerGeneratedFiles>true</EmitCompilerGeneratedFiles>
<CompilerGeneratedFilesOutputPath>Generated</CompilerGeneratedFilesOutputPath>
<IsRoslynComponent>true</IsRoslynComponent>
<LangVersion>latest</LangVersion>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.CodeAnalysis" Version="4.2.0" PrivateAssets="all" />
<PackageReference Include="Microsoft.CodeAnalysis.Analyzers" Version="3.3.3" PrivateAssets="all" />
<PackageReference Include="Microsoft.CodeAnalysis.CSharp" Version="4.2.0" PrivateAssets="all" />
<PackageReference Include="Microsoft.SqlServer.Management.SmoMetadataProvider" Version="161.47021.0" />
<PackageReference Include="Microsoft.SqlServer.Management.SqlParser" Version="160.22506.0" />
</ItemGroup>
<ItemGroup>
<None Include="$(OutputPath)\$(AssemblyName).dll" Pack="true" PackagePath="analyzers/dotnet/cs" Visible="false" />
</ItemGroup>
</Project>
and for the test console app:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net6.0</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.SqlServer.Management.SmoMetadataProvider" Version="161.47021.0" />
<PackageReference Include="Microsoft.SqlServer.Management.SqlParser" Version="160.22506.0" />
<PackageReference Include="System.Data.SqlClient" Version="4.8.3" />
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..\sql_modeler.generator\sql_modeler.generator.csproj" OutputItemType="Analyzer" ReferenceOutputAssembly="false" />
<ProjectReference Include="..\sql_modeler\sql_modeler.csproj" />
</ItemGroup>
</Project>
I'm trying to build an application for release. However, no matter what I do, it needs to have the runtimeconfig.dev.json in the directory, otherwise it won't even run, I get no errors when it does this.
I've tried compiling it so it will produce a single file but then it doesn't work at all even when runtimeconfig.dev.json is included in the directory.
Whilst trying to publish through the interface in Visual Studio the parameters are as followed:
Configuration: release
Target Framework: netcoreapp3.1
Target Runtime: win-x64
Also using the dotnet publish -c Release command, this still results in a file dependent on runtime.dev.json
I've also tested the output of the publish on another computer and it just doesn't run at all without any error. Even with the runtimeconfig.dev.json In the directory. Even after changing the framework from 3.1 to 5.0 and then back, it still doesn't work on another computer. I don't understand why as the program works perfectly fine when I run it via visual studio with both the debug and release configurations it's when I'm trying to do it independently is when there is problems.
Here is what my .csproj file looks like.
<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
<PropertyGroup>
<OutputType>WinExe</OutputType>
<TargetFramework>netcoreapp3.1</TargetFramework>
<UseWPF>true</UseWPF>
<ApplicationIcon>Starter-Edit-Icon.ico</ApplicationIcon>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|AnyCPU'">
<DocumentationFile></DocumentationFile>
</PropertyGroup>
<ItemGroup>
<Compile Remove="Properties\DataSources\**" />
<EmbeddedResource Remove="Properties\DataSources\**" />
<None Remove="Properties\DataSources\**" />
<Page Remove="Properties\DataSources\**" />
</ItemGroup>
<ItemGroup>
<None Remove="Starter-Edit-Icon.png" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="Costura.Fody" Version="5.7.0">
<PrivateAssets>all</PrivateAssets>
<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
</PackageReference>
<PackageReference Include="Extended.Wpf.Toolkit" Version="4.1.0" />
</ItemGroup>
<ItemGroup>
<Resource Include="Starter-Edit-Icon.png" />
</ItemGroup>
</Project>
This is what the runtimeconfig.dev.json file contains
{
"runtimeOptions": {
"additionalProbingPaths": [
"C:\\Users\\MyUserName\\.dotnet\\store\\|arch|\\|tfm|",
"C:\\Users\\MyUserName\\.nuget\\packages"
]
}
}
I fixed this issue by removing the unused frameworks from my dependencies, I also uninstalled any NuGet packages that was unused which happened to be both of them I had imported anyway.
I'm trying to create a layer for my lambda function developed with Net core 3.1, but I get the following error:
zipping: Failed to compress file: open
dotnetcore\store\x64\netcoreapp3.1\microsoft.extensions.dependencyinjection.abstractions\
5.0.0\lib\netstandard2.0\Microsoft.Extensions.DependencyInjection.Abstractions.dll:
The system cannot find the path specified.
The command that I'm using is:
dotnet lambda publish-layer --region us-east-1 --layer-name my-Layers --layer-type runtime-package-store -sb sb-layers -f netcoreapp3.1 --package-manifest package-manifest.xml
The package manifest is the following:
<Project Sdk="Microsoft.NET.Sdk">
<ItemGroup>
<PackageReference Include="Amazon.Lambda.APIGatewayEvents" Version="2.4.0" />
<PackageReference Include="Amazon.Lambda.Core" Version="2.0.0" />
<PackageReference Include="Amazon.Lambda.Serialization.SystemTextJson" Version="2.1.0" />
<PackageReference Include="AWSSDK.DynamoDBv2" Version="3.7.0.73" />
<PackageReference Include="Microsoft.Extensions.DependencyInjection" Version="5.0.2" />
<PackageReference Include="Microsoft.Extensions.DependencyInjection.Abstractions" Version="5.0.0" />
<PackageReference Include="Newtonsoft.Json" Version="13.0.1" />
</ItemGroup>
</Project>
I see that the file path with the error has "netstandard2.0" but I don't know why. Maybe my question is silly, does this mean that I cannot used "microsoft.extensions.dependencyinjection.abstractions" with Net Core 3.1?
Thanks a lot for any information about how to deal with this issue.
I tried creating the package and didnt fail at any point
So, this is what i did.
Updated the dotnet distribution and fresh install aws lambda tools
sudo apt-get install -y dotnet-sdk-5.0
dotnet tool install -g Amazon.Lambda.Tools
I used the sample DemoLayer as instructed by the AWS tutorials
AWS tutorial
dotnet lambda publish-layer DemoLayer --layer-type runtime-package-store -sb <s3bucket> --package-manifest manifest.xml
and above command line uploads all the Package Reference without any error.
I recently updated my Visual Studio version from 2017 to 2019 also installing the .net core version 2.2. I had .Net Core 2.0 web projects which only contained the dlls that were added through out the Nudget packaging system which looks like this;
This folder contains only 22 items.
But after the VS update when I publish the application I have an output folder which looks like this;
This folder contains almost 200 dlls. I did not even change the publishing settings. I do not have any of these dependencies, and I am making sure that the deployment method is not self-contained deployment but Framework-dependent Deployment
I am using the CLI command to publish my application;
dotnet publish -c Release
What is the reason I have this many dlls on my published folder ?
Edit:
Here is how my .csproj file looks like:
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="AstrodyneTdi.Web" Version="3.2.4" />
<PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.0" />
<PackageReference Include="NLog.Extensions.Logging" Version="1.0.0-rtm-alpha4" />
<PackageReference Include="RestSharp" Version="106.6.9" />
</ItemGroup>
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.0" />
</ItemGroup>
</Project>
For me I had to add this section to the .csproj file a while ago, specifically PublishWithAspNetCoreTargetManifest
MS Documentation
<PropertyGroup>
<TargetFramework>netcoreapp2.2</TargetFramework>
<Platforms>AnyCPU;x64</Platforms>
<PublishWithAspNetCoreTargetManifest>true</PublishWithAspNetCoreTargetManifest>
</PropertyGroup>
I am trying to migrate a WPF app built under the old csproj format to the new csproj format defined for VS2017.
I've been able to get the app to compile, but I when I try to launch it in the debugger under VS2017 I get the following error message:
Unable to run your project. The "RunCommand" property is not defined.
Interestingly, if I double-click the exe within File Explorer it launches just fine.
FYI, the project was initially a console app, which I then modified to be a WPF app. Here's the csproj file:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<LanguageTargets>$(MSBuildExtensionsPath)\$(VisualStudioVersion)\Bin\Microsoft.CSharp.targets</LanguageTargets>
<OutputType>winexe</OutputType>
<TargetFramework>net47</TargetFramework>
<ApplicationIcon />
<OutputTypeEx>winexe</OutputTypeEx>
<StartupObject />
</PropertyGroup>
<ItemGroup>
<EmbeddedResource Update="Properties\Resources.resx" Generator="ResXFileCodeGenerator" LastGenOutput="Resources.Designer.cs" />
<Compile Update="Properties\Resources.Designer.cs" DesignTime="True" AutoGen="True" DependentUpon="Resources.resx" />
<Compile Update="Settings.Designer.cs" AutoGen="True" DependentUpon="Settings.settings" />
<None Update="Settings.settings" LastGenOutput="Settings.Designer.cs" Generator="SettingsSingleFileGenerator" />
<Page Include="**\*.xaml" SubType="Designer" Generator="MSBuild:Compile" Exclude="App.xaml" />
<Compile Update="**\*.xaml.cs" SubType="Designer" DependentUpon="%(Filename)" />
<Resource Include="assets\*.*" />
<ApplicationDefinition Include="App.xaml">
<Generator>MsBuild:Compile</Generator>
<SubType>Designer</SubType>
</ApplicationDefinition>
</ItemGroup>
<ItemGroup>
<PackageReference Include="Autofac" Version="4.6.0" />
<PackageReference Include="Autofac.Extras.CommonServiceLocator" Version="4.0.0" />
<PackageReference Include="Extended.Wpf.Toolkit" Version="3.0.0" />
<PackageReference Include="Hardcodet.NotifyIcon.Wpf" Version="1.0.8" />
<PackageReference Include="MaterialDesignColors" Version="1.1.3" />
<PackageReference Include="MaterialDesignThemes" Version="2.3.0.823" />
<PackageReference Include="MvvmLightLibs" Version="5.3.0" />
<PackageReference Include="Serilog" Version="2.4.0" />
<PackageReference Include="Serilog.Sinks.RollingFile" Version="3.3.0" />
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..\..\WPFUtilities\J4JUI\J4JUI.csproj" />
</ItemGroup>
<ItemGroup>
<Reference Include="System.ComponentModel.DataAnnotations" />
</ItemGroup>
<Import Project="$(MSBuildSDKExtrasTargets)" Condition="Exists('$(MSBuildSDKExtrasTargets)')" />
</Project>
Where is the RunCommand property set, and how do I set it?
Update
Playing around with the project settings, I configured the debug options to launch the executable created by the project (the default is to "run" the project).
This lets me launch the app in the debugger within VS 2017...and makes me think this might be a bug in VS 2017, with the RunCommand property not being defined by the build environment the way it should be.
For the 1.0.0 and 1.1.0 SDK, the Microsoft.NET.Sdk.targets file tries to set the RunCommand property when Condition="'$(TargetFrameworkIdentifier)' == '.NETFramework' and '$(OutputType)' == 'Exe'". But since the project specifies <OutputType>winexe</OutputType> (which it needs to), the condition is not satisfied (and of course none of the others are either).
This seems to have been fixed in the upcoming 2.0.0 SDK (source, you'll have to explore the other files to find the _IsExecutable property), which should be shipped in the next VS2017 update.
In the meantime I opted to set the property manually in my .csproj: <RunCommand>bin\Debug\net47\MyApp.exe</RunCommand> (I could've spent more time to use more SDK-defined properties, but I'd have to schedule it after the SDK targets are imported, which I've left out for simplicity)
What kind of "migrate" are we talking here? There is no in-built migration tool, and it's way more than the previous "VS 2012 to VS2013" type upgrade, it's a fundamentally different format all together.
I know some people have tried (unsuccessfully) to manually update the .csproj XML, it usually ends in frustration and getting no where with it.
Honestly I would 100% recommend making brand new projects and manually copying your files in. Will take a while, but at least you'd be totally sure it was actually going to work, and you don't spend hours trying banging your head on the wall with the barely documented new XML format.
Of course a better option would be something built in to do it for you.