I installed the .NET SDK 2.1.301-win-x64.exe and afterwards updated all the nuget packages to 2.1.1.
In my WebApp I have the Nuget Package Microsoft.AspNetCore.All 2.1.1 and Microsft.NETCore.App 2.1.0. In the Nuget Window I see that there's also the Version 2.1.1, but I can't select it (Blocked by Project)
Same story in my Console App: Microsft.NETCore.App 2.1.0
My first question: Is here already something wrong? Or is this expected behavior?
If I build the WebApp as self contained App, that works well.
If I biuld the Console App as self contained App (Self-contained / win-x64). I get the follwoing Error:
The project was restored using Microsoft.NETCore.App version 2.1.1,
but with current settings, version 2.1.0 would be used instead. To
resolve this issue, make sure the same settings are used for restore
and for subsequent operations such as build or publish. Typically
this issue can occur if the RuntimeIdentifier property is set during
build or publish but not during restore."
The source of this error is a referenced project.
What do I do wrong? Let me know if you need additional information, then I will add it.
This is a known issue for the moment. In your referenced project's csproj file, set the TargetLatestRuntimePatch property:
<PropertyGroup>
<TargetLatestRuntimePatch>true</TargetLatestRuntimePatch>
</PropertyGroup>
This only happens when a .NET Core application references another .NET Core application and self-contained roll-forward only partially kicks in during publish.
For portable applications, it is enough to target 2.1.0 version of Microsoft.NETCore.App and when run on a target machine, the latest patch available on the machine will be used automatically. In recent tooling, a change was made so that the tooling would use the latest known patch version for self-contained applications so you automatically bundle the latest patch release with your application. However, this doesn't flow over project-to-project references.
See Self-contained deployment runtime roll forward for more information.
Related
I use UIAutomationClient.dll in a Framework project which I'm moving to Core. This will only be on Windows so it's OK. But I need to reference it in way that can be run on differenet windows machines. There is a nuget package for this, commented that it should not be referenced directly. So how do I get it? If I go ahead and choose it, I get the error:
package type DotnetPlatform that is incompatible with this project
Please note: this is a console application which does some UI automating. It's not a desktop app, not WPF.
As vatsan-madhavan wrote on GitHub, you can use:
<ItemGroup>
<FrameworkReference Include="Microsoft.WindowsDesktop.App.Wpf" />
</ItemGroup>
Learning from all the problems with the BCL packages in .NET Core 1.x and 2.x, starting from .NET Core 3.0, the .NET Core SDK and NuGet support FrameworkReference, which does not use version numbers (the SDK tells NuGet which version to download). Since it's so new, it's not well known, or frequently documented.
I'm getting the error.
The command:
"C:\ProjectDir\.nuget\NuGet.exe" install "packages.config"
-source "https://www.nuget.org/api/v2/"
-NonInteractive
-RequireConsent
-solutionDir "C:\ProjectDir\ "
exited with code
-1073741502 while building one of my Class Library projects in my solution.
As a result, I'm getting many
Metadata file 'C:\ProjectDir\src\ProjectName\bin\ProjectName.dll' could not be found`
errors from other projects in my solution.
When I click on restore packages for the solution it shows that there are no packages to restore.
Any idea about the fix?
While it's interesting to know that NuGet exited with an error code, it's far more interesting and useful to know what the program's output is. By not sharing that with us, we have to do a lot of guessing, reducing the chance that you get an answer that helps your specific case.
Anyway, NuGet.exe's program returns 1 for almsot all error codes (unless something throws an ExitCodeException, but it appears that only signing related code returns anything other than 1). Therefore, I conclude that NuGet didn't actually run. My best guess is that you ran on a machine without recent versions of the .NET Framework installed, but you're running a newish version of nuget.exe that needs a newer .NET Framework.
You also didn't say what version of nuget.exe you're using. NuGet 5.x is designed for Visual Studio 2019, which has a minimum requirement of the .NET Framework 4.7.2. NuGet 4.x is designed for Visual Studio 2017, which has a requirement of .NET Framwork 4.6. However, Wikipedia says that the .NET Framework was released in April 2018, which suggests to me that if you don't have that installed, you're not running Windows Update and so you're probably vulnerable to all sorts of malware. Perhaps you've just turned off recommended updates and getting only the critical updates, but it's worth checking.
So, while I expect this to be the cause of the problem, I also want to comment that it's normal to run nuget restore, not nuget install, to restore packages for projects and solutions. Also, it's typical to simply run nuget restore mysolution.sln. This has several benefits. NuGet can restore the entire solution more efficiently than one project at a time. Secondly you no longer need to provide the -SolutionDir argument.
One possibility about why you're restoring one project at a time is hinted by the fact that you're running some_path\.nuget\nuget.exe. This was done in Visual Studio 2010, VS2012 and VS2013, but was removed from VS2015 onwards. Back then it was enabled by right clicking the project and selecting "Enable NuGet restore for solution" or something like that. This was because NuGet was not really integrated with Visual Studio back then, other than adding this command which would modify all your .NET project files and create the .nuget/ directory with 3 files. Since then NuGet is integrated with Visual Studio and can do automatic restores without hacking project files, so it's no longer needed. NuGet has docs on migrating to automatic package restore.
The only advantage of the old package restore that changes the .NET project files is that on a CI machine there's nothing extra to do. Simple clone the repo and run msbuild. Once it's removed, it's necessary to run nuget restore on the solution file before building, to restore packages.config projects. If you can migrate to PackageReference (needs Visual Studio 2017 or later), then the NuGet restore step isn't necessary, you can run msbuild /restore mysoltuion.sln, or if all projects in the solution are SDK style, just dotnet build. Although some people still prefer to separate restore and build into separate steps, so when there's a failure, it's more obvious if it was a restore or compile error.
I have a .NET Core library -- .NET Core 1.1 app -- and wanted to install the SQL Server client. I get the following screen in NuGet.
What are these runtime natives? I really want to keep the app nice and clean by sticking to only .NET Core and not mix and match .NET Core with .NET Framework.
Any idea what these runtime natives are? Will they affect the app's portability to say Linux or MacOS?
You are adding the NuGet PackageReference from Visual Studio, that's why you're seeing those runtime native libraries being installed.
What's really happening in the background is:
The <PackageReference Include="System.Data.SqlClient" Version="4.3.0" /> is being added to the .csproj file;
The dotnet restore command is being run, which determines your current runtime and restores the dependencies according to that.
So when you're referencing System.Data.SqlClient the restore command restores the it's dependencies according to your current runtime, which is Windows.
Answering your question: it won't affect portability because if the restore is made with a different target runtime (eg. osx.10.12-x64) it will bring down the runtime natives specific to that.
When developing an ASP.NET 5 app, I can install the mono runtime into it via NuGet. For example, the latest to date dnx-mono.1.0.0.rc1-update1.
As far as I've tested, the thing is the actual runtime I'm installing on, for example, Linux via DNVM tool to run ASP.NET apps on it.
If I installed the package into a project, I can't then chose it in project properties, nor I can chose it when publishing into a folder - only Windows clr versions are available.
So what's the point of installing it right into the application project?
Or maybe it is not intended to be installed into a project, but exists solely for DNVM could find and pick it up?
You're right. It is used by DNVM and your application should never reference it directly.
I'm trying to build a VS2015 ASP.NET v5 web app on our build server (basically, outside of Visual Studio). Our existing scripts simply invoke msbuild with the csproj file, but with this project I get:
Project File is empty
What is the "story" for "building" these new webapps outside Visual Studio? I believe they can still target .NET 4.5 (I hope so, as we're not upgrading web servers any time soon) so assumed it were possible.
Well there is no .csproj in a dnx project everything that is needed for dnu to build a project is contained in the project.json. There is a xproj file but you can ignore that. Microsoft has finally decided to see the light and uses xproj just for VS specific "stuff" and IDE agnostic project details are put in the project.json.
So to build a dnx project all you need is the right version of dnx and the project source code. Now AFAIK there are no out of the box solutions but everything is done with command line commands so script something up should be easy. It all depends on how robust of a solution you want to build.
To build a dnx project from the command line (assuming you have the proper dnx installed and set to active) it is just two commands. dnu restore runs a dependency check and dnu (a part of dnx) has a built in nuget client so it will reach out and grab dependencies if needed. dnu build runs that actual compilation.
So cd to the project root (which contains project.json) and run dnu restore then dnu build.
It gets more complex if you need to dynamically support different dnx versions. Keep in mind dnx versions are identified by runtime (coreclr or clr), architecture (x86, x64, etc), and a version number. So if you are only targetting say x64 builds on clr (full .net runtime) that eliminates two variables but what happens if a project requires a newer version of the runtime than what is installed on the build server? As an example say you installed (manually using dnvm) dnx-clr-win-x64.1.0.0-beta4 on the build server but at some point in the future a developer requires dnx-clr-win-x64.1.0.0-beta6-1200 to resolve a bug.
The simplistic solution would be just to install new runtime versions as needed and build all projects against the newest one needed. This isn't as bad as it might first sound. Once dnx gets out of beta changes to the runtime should be infrequent. Remember the runtime is the very low level code and unmanaged dlls. It is the bootstrapping stub that the BCL sits on top of. Hopefully there should not be that many changes to the dnx for a given OS, architecture and runtime.
For a more robust solution you could use scripting to find the runtime version required for a project. It is found in a solution level global.json. The script could then use dnvm list to determine if it has that runtime installed. If it doesn't then use dnvm install or dnvm upgrade to install the required version. Before starting the build it would use the command dnvm use to make the correct runtime active and then proceed with dnu restore and dnu build.
Honestly I expect some pretty robust solutions to come along. Task runners (gulp, grunt, etc) are first class citizens in .NET 5. Most likely your workflow will involve bower for client side dependency resolution, npm, grunt/gulp and some task packages for things like minifying js files. The build server is going to need all that as well so having a build task as a grunt or gulp package seems a pretty good fit.