Develop Reference

Application won't run without runtimeconfig.dev.json in the directory?

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.

NUnit TestRunner working directory is different depending on target framework of project

I am developing a library which has a test project in the solution. The library uses several framework from the .NET universe (like net462 or netcoreapp2.0) and works fine. The test project currently uses netcoreapp2.1 and the latest NUnit framework and test runner.
I have tests that rely on files that are included in the test project and are copied to the output folder during the build process. When the test project uses .NET Core as target framework, the files are found and the tests pass. When the test project uses anything else than .NET Core (I didn't test all .NET Framework versions, but some), the files are not found and the tests fail.
When not using .NET Core the working directory of the test runner seems to be located at C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\ which is not the project's output directory.
This is the not working project file
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net461</TargetFramework>
<IsPackable>false</IsPackable>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|AnyCPU'">
<OutputPath>bin\Release\</OutputPath>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
<OutputPath>bin\Debug\</OutputPath>
</PropertyGroup>
<PropertyGroup>
<AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.8.0" />
<PackageReference Include="NUnit" Version="3.10.1" />
<PackageReference Include="NUnit3TestAdapter" Version="3.10.0" />
</ItemGroup>
</Project>
And this is the working project file
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netcoreapp2.1</TargetFramework>
<IsPackable>false</IsPackable>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|AnyCPU'">
<OutputPath>bin\Release\</OutputPath>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
<OutputPath>bin\Debug\</OutputPath>
</PropertyGroup>
<PropertyGroup>
<AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.8.0" />
<PackageReference Include="NUnit" Version="3.10.1" />
<PackageReference Include="NUnit3TestAdapter" Version="3.10.0" />
</ItemGroup>
</Project>
Does anyone know more about this behaviour? How do I fix this?

As explained in the cited issue, NUnit does not change the current working directory at all. This is by design, based on the notion that library programs should never change the cd but should leave it as set by the calling program.
There may be reasons why either the runner or Visual Studio itself changes the directory in the case of a .NET Core project. I don't know what they are but I do know that NUnit doesn't do it.
The obvious workaround is to use TestContext.TestDirectory in your tests. It is provided by NUnit for this purpose. Note that it only works in test code. If you need something similar outside of the test code, you can copy the logic from TestContext.TestDirectory, which is quite well tested.

Nuget Conflicting projectreference and packagereference

I'm running a ASP.NET Core app on the .NET 4.6.1 framework. I have 1 solution with multiple projects in it. All of the projects are class libraries that reference each other via PackageReferences in their .csproj (this way we can build, package and version them independently). However, I want to be able to test their integration with one another without needing to push them up to NuGet first - aka I want to use them as ProjectReferences in the solution, but PackageReferences when building them through my Jenkins build process in order to version the components separately.
When .NET Core was project.json based, this worked fine. I would set the version at the top of the project.json and if a project existed with that version in the solution it would reference it as a project, otherwise it would look for it on my NuGet feed.
The problem with using ProjectReferences is that all project's would get the same version when they are built and sent to NuGet.
Is there any way to do this in csproj? Look for a project reference if it exists, otherwise look at NuGet?
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<VersionPrefix>1.3.0</VersionPrefix>
<TargetFramework>net461</TargetFramework>
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
<AssemblyName>MyProject1</AssemblyName>
<PackageId>MyProject1</PackageId>
<NetStandardImplicitPackageVersion>1.6.1</NetStandardImplicitPackageVersion>
<GenerateAssemblyConfigurationAttribute>false</GenerateAssemblyConfigurationAttribute>
<GenerateAssemblyCompanyAttribute>false</GenerateAssemblyCompanyAttribute>
<GenerateAssemblyProductAttribute>false</GenerateAssemblyProductAttribute>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="MyProject2" Version="1.4.0-*" />
<PackageReference Include="Microsoft.AspNetCore.Http" Version="1.1.1" />
<PackageReference Include="Microsoft.AspNetCore.Http.Abstractions" Version="1.1.1" />
<PackageReference Include="Microsoft.Extensions.Logging.Abstractions" Version="1.1.1" />
<PackageReference Include="Microsoft.AspNetCore.Hosting.Abstractions" Version="1.1.1" />
</ItemGroup>
<ItemGroup Condition=" '$(TargetFramework)' == 'net461' ">
<Reference Include="System" />
<Reference Include="Microsoft.CSharp" />
</ItemGroup>
</Project>
Above is an example, I would like MyProject2 to be referenced by ProjectReference if 1.4.0 exists in the solution.

I recently was try to do the same thing and couldn't find the answer but figured out something that works for me. You can use the Exists condition in MSBuild for the csproj to include the project reference when its there and exclude the package reference if its there:
<Project Sdk="Microsoft.NET.Sdk">
...
<ItemGroup>
<PackageReference Condition="!Exists('[path-to-project].csproj')" Include="[package-id]" Version="[pacakage-version].*" />
</ItemGroup>
...
<ItemGroup>
<ProjectReference Condition="Exists('[path-to-project].csproj')" Include="[path-to-project].csproj" />
</ItemGroup>
...
</Project>

netcoreapp2.0 with netstandard2.0

I have a project(x) that targets the NetStandard.Library 2.0 and a console app that targets netcoreapp2.0.
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp2.0</TargetFramework>
</PropertyGroup>
<PropertyGroup>
<PackageTargetFallback>$(PackageTargetFallback);portable-net45+win8+wp8+wpa81;</PackageTargetFallback>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.0.0" />
<PackageReference Include="Microsoft.AspNetCore" Version="1.1.0" />
<PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.1" />
<PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="1.1.0" />
<PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="1.1.0" />
<PackageReference Include="Microsoft.VisualStudio.Web.BrowserLink" Version="1.1.0" />
<PackageReference Include="NETStandard.Library" Version="2.0.0-beta-25021-01" />
<PackageReference Update="Microsoft.NETCore.App" Version="2.0.0-beta-001588-00" />
</ItemGroup>
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="1.0.0-msbuild3-final" />
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..\x.csproj" />
</ItemGroup>
</Project>
Project X:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.Extensions.Logging" Version="1.1.0" />
</ItemGroup>
<ItemGroup>
<PackageReference Update="NETStandard.Library" Version="2.0.0-beta-25017-01" />
</ItemGroup>
</Project>
When I compile the console application I get the Error:
Project x is not compatible with netcoreapp2.0 (.NETCoreApp,Version=v2.0) / win-x86. Project x supports: netstandard2.0 (.NETStandard,Version=v2.0)
I have installed: Microsoft net core 2.0.0 runtime located here: https://github.com/dotnet/core-setup but it still doesnt build.
*edited following advice from below:
I have installed the Alpha SDK located here: https://github.com/dotnet/cli/tree/master#installers-and-binaries and I still get the same error.
The interesting thing is that there is a nuget package reference for Microsoft.NETCore.App which I cannot remove:

.NET Core 2.0 will require the .NET Core 2.0 SDK. Download links to nightlies are available here: https://github.com/dotnet/cli/tree/master#installers-and-binaries
Heads up: nightly builds of this are very unstable right now. As of February 2017, .NET Core 2.0 has no public release. Checkout https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/dogfooding.md for instructions on using nightlies.

.NET Core 2.0 SDK (final release) is available including tools for vs 2017 /2015.
You can download and it's integrated with vs 2017.3
Note that if you installed this version: dotnet-sdk-2.0.0-win-gs-x64, it didn't show in visual studio 2017.3,ref
For feature details read: Announcing .NET Core 2.0
Also, ASP.NET Core 2.0 is available

.NET Core 2.0 is not on the Download page and it is expected to be released in Q2 2017 on the roadmap.
You should use .NET Core 1.1 and target .NET Standard 1.6 for now.
And yes: you must download the SDK if you want to develop.

if you have both Core and DotNet 4.X within the same solution, you may want to consider adding netcoreapp2.0 to your "<\TargetFramework>" tag.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0;netcoreapp2.0</TargetFramework>
</PropertyGroup>

Compiling .NET Core VS17

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