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.
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 know nuget.org does not have this functionality yet, but I have been searching for release notes on the nuget package developer websites, and this is taking longer than expected, since I have a lot of nuget packages installed on my .net framework project.
Is there a better way to do this? maybe someone has already done it and posted a list somewhere?
thanks in advance
If you change the 'n' in the nuget URL to an 'f', so it becomes fuget, you'll get a list of which frameworks the package targets. If you see it targets a netstandard version then it will work with .NET Core.
If your project is using an "old" style csproj with packages.config, the first step is to migrate to using PackageReference instead. Here's some docs. As the docs say, there are some differences between how packages.config and PackageReference works. If you're affected, you're blocked until you can make your project work with PackageReference.
If your project is using an "old" style csproj with PackageReference (for example you did the migration above), then migrate to SDK-based csproj so you can build with the dotnet CLI. Here's a blog post with details how to do it.. Note you you can keep using the Windows .NET Framework with SDK csproj. Although SDK-based csproj came out at the same time as .NET Core, it's not necessary to use .NET Core with the new project style. If your project is a class library or console app, you're definitely fine, otherwise you need to research to find out if the project type is compatible with SDK projects or not.
Once you have your .NET Framework project working with SDK projects, either change the TargetFramework to netcoreapp or netstandard, or you can multi-target your project by changing TargetFramework to TargetFrameworks, and use a semi-colon separated list of TFMs you want to target. For example <TargetFrameworks>net461;netcoreapp2.1</TargetFrameworks>. Then simply run dotnet restore and if any of the packages you use is not compatible with .NET Core, restore will fail, and you simply revert to target only .NET Framework.
In summary, once your project uses SDK-based csproj, it takes 10 seconds to test if your dependencies are compatible with .NET Standard/.NET Core. If your project is not yet using SDK-based csproj, you undo your change to the TargetFramework(s) line in your csproj and continue with your life until the next time you test again. If you're not already on SDK-based csproj and there's nothing blocking you from doing so, then doing the upgrade is low risk and bring some benefits, such as fewer merge conflicts on the file, much easier to create nupkgs for any packages you maintain, and being able to test against .NET Core compatibility in seconds.
Alternative: If you're unable or unwilling to migrate to SDK-based projects and you want to check if your dependencies are compatible, then use dotnet new classlib to create a new .NET Core project, add package references to the same packages that your existing project uses, then try to restore. If you have a big solution with lots of projects and/or references, just write a small program to read your packages.config/csproj files as XML, find unique list of packages that you use, then write a new SDK-based csproj targeting .NET Core with all the packages you just found as package references.
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.
In previous versions of what is now .NET Core, using the dnx toolchain, it was possible to run an application straight from source code, without compiling to a DLL on disk. This capability was also present on Azure, allowing you to edit code on the server and have those changes reflected in the live site.
The new dotnet CLI run command seems to automatically create the familiar bin and obj folders with compiled DLLs in them, and the publish process from Visual Studio to Azure now no longer includes the C# source, just the DLL.
Is it no longer possible with the new CLI and other tools to run .NET Core code without creating a DLL on disk?
Short David Fowler response:
Dynamic compilation is gone in RC2. It only exists for views now. There are no plans to bring it back.
Why?
Architectural challenges and changes require to implement it on both .NET Framework and .NET Core. We did it with dnx and there were some problems (like some things being completely broken with in memory assemblies) that we chose to just avoid.
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.