I have a small benchmark project that is targeting netcoreapp2 and net462.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFrameworks>netcoreapp2;net462</TargetFrameworks>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="BenchmarkDotNet" Version="0.11.5" />
</ItemGroup>
</Project>
However when running this benchmark it only seems to respect the netcoreapp target and not the full framework one. It states that the CLR job was run targeting net472. Could I be doing this wrong or is this an issue? I have targeted only two jobs [CoreJob, ClrJob].
[Host] : .NET Core 2.0.9 (CoreCLR 4.6.26614.01, CoreFX 4.6.26614.01), 64bit RyuJIT
Clr : .NET Framework 4.7.2 (CLR 4.0.30319.42000), 64bit RyuJIT-v4.7.3394.0
Core : .NET Core 2.0.9 (CoreCLR 4.6.26614.01, CoreFX 4.6.26614.01), 64bit RyuJIT
I have also noticed that even if I remove the explicit job attributes and only target my project to net462 the run summary still shows it executes with net472.
As described in BenchmarkDotNet docs: https://benchmarkdotnet.org/articles/configs/toolchains.html#multiple-frameworks-support
Full .NET Framework always runs every .NET executable using the latest .NET Framework available on a given machine. If you try to run the benchmarks for a few .NET TFMs, they are all going to be executed using the latest .NET Framework from your machine. The only difference is that they are all going to have different features enabled depending on target version they were compiled for. You can read more about this https://learn.microsoft.com/en-us/dotnet/framework/migration-guide/version-compatibility and https://learn.microsoft.com/en-us/dotnet/framework/migration-guide/application-compatibility. This is .NET Framework behavior which can not be controlled by BenchmarkDotNet or any other tool.
Related
I have a SDK styled .Net class library which compiles properly on my local machine, however fails on build server.
The contents of .csproj are
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>net35;net40;netstandard1.0</TargetFrameworks>
<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
<Version>1.5.6</Version>
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
</PropertyGroup>
</Project>
The error displayed is:
NETSDK1045: The current .NET SDK does not support targeting .NET Standard 4.0. Either target .NET Standard 2.1 or lower, or use a version of the .NET SDK that supports .NET Standard 4.0
I have .NET Core 3.1.113 installed on build server and .NET 5 installed on local machine.
Note: If I remove netstandard1.0 from TargetFrameworks then build succeeds on both the machines. However I want my library to target .net standard 1.0 as well.
I cannot understand why v4.0 is treated as .NET Standard 4.0 on build server. Can anyone let me know what the problem might be?
Remove the following line from your .csproj file:
<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
This overrides the version value that the SDK infers from TargetFramework which will interfere with your definition of net3.5 and so on - you were actually building .NET Framework 4.0 twice and then override netstandard1.0 to .NET Standard (inferred TargetFrameworkIdentifier) to 4.0. Newer versions of the SDK may have different inference logic which may be a difference between 3.1 and 5.0 SDKs but this is an error in the csproj nonetheless.
If your build logic relies on TargetFrameworkVersion being defined in the project I suggest you try to change your build logic - this is VERY DANGEROUS to have in a modern csproj file where you rely on TargetFramework and TargetFrameworks (plural). You can also try to move it into a separate <PropertyGroup> with an always-fals-condition (e.g. <PropertyGroup Condition="'$(ThisIsToWorkAroundBuildScripts)' == 'True'">)
I cannot understand why v4.0 is treated as .NET Standard 4.0 on build
server. Can anyone let me know what the problem might be?
That is quite strange and I have not seen that issue before. And there is no info about .NET Standard 4.0 and I did not know why VS treats v4.0(net framework 4.0) as net standard 4.0. Maybe your there is some problems about your server environment.
Please follow these:
1) First, please use dotnet --list-sdks under CMD to check if you installed net core 2.1 sdk or any other versions. And actually, net core 2.1 sdk could support the previous sdks including net standard 1.0. Maybe you would better install net core 2.1 sdk. Also, you could install the latest Net Core 3.1 Sdk.
2) check system environment variable, and find whether there is a variable called MSBuildSDKsPath, if so, please delete it. Then, restart.
3) delete bin and obj folder under the build server. Also, I suggest you would better use Build Tool for VS to build your projects on the server rather than dotnet build. dotnet cli does not contain the tool for net framework. What's more, your project is multi-targetframeworks, it could build net core and net standard, and also you have to download net framework sdk.
That is too complex, you could install the Build Tool for VS2019(more likely a lightweight cmd which integrates dotnet, net framework, all vs environment). Also, install the Net desktop build tool and net core build tool workload, also install the related sdks.
When you finish it, delete bin and obj folder, type this under Build Tool for VS command:
msbuild xxx\xxx.csproj -t:clean,restore,build
Related to "Free Startup Templates" for the last ABP 3.0 version, what are the differences between the Full .NET Framework and .Net Core (Cross Platform) versions?
I presume you are talking about the ASP.NET Core 2.0 target framework, either Full .NET Framework and .NET Core (Cross Platform)?
I think the code is more-or-less the same (as mentioned by #Alper Ebicoglu the .NET Core project is missing the SignalR implementation) but the output from the build will be for .NET Framework 4.6.1 as supposed to for .NET Core.
Basically they're building a .NET Framework project using .NET Core tools which you can do.
For example:
Create a temp folder and open Command Prompt or PowerShell in that directory. Then run dotnet new console, then dotnet restore and finally dotnet build. You should get a message like temp -> C:\Source\temp\bin\Debug\netcoreapp2.0\temp.dll
Edit the .csproj file and change the TargetFramework property to net461. Run dotnet build and you'll see a different message temp -> C:\Source\temp\bin\Debug\net461\temp.exe.
In the first instance you created a .dll to run cross platform using dotnet run and in the second instance you created a .exe which will only run on the Windows platform.
I hope I'm answering what you're asking and this helps.
if we talk about only aspnetboilerplate framework; the only main difference is, currently in .NET Core platform SignalR implementation is missing.
Looks like when I run TeeChartNET2015EVAL_4.1.2015.12166.exe, it installs version of TeeChart.dll built on framework 4.5 only. I need to do the evaluation with the dll built with framework 3.5 (because I have to integrate to an already existing application based on Framework 3.5). Is there any way I can get the evaluation dll for Framework 3.5?
Thanks
When running the installer you need to choose which environments do you want the assemblies for. If you choose Visual Studio 2008 this will install .NET Framework 3.5 assemblies as this is the default framework supported by this environment.
I will try to explain this as clear as I can
I want to fully understand how MSBuild multitargeting works.
I have read several articles from Microsoft and I think I understand the basic but I want to be sure I am not missing anything.
According to Microsoft:
By using Visual Studio, you can compile an application to run on any one of several versions of the .NET Framework. For example, you can compile an application to run on the .NET Framework version 2.0, and compile the same application to run on the .NET Framework version 4. The ability to compile to more than one framework is named multitargeting.
Visual Studio runs under the most current version of the .NET Framework that is installed on the development computer.
http://msdn.microsoft.com/en-us/library/ee395432.aspx
So do this mean that Visual Studio always calls MSBuild from the latest framework installed? assuming Visual Studio 2010 is installed, it will always call: %WINDIR%\Microsoft.NET\Framework\v4.0.30319\MsBuild.exe when building any project targettting any .Net Framework version right???
If yes, then the ability to target old .Net Framewrok versions is based on the ToolsVersion and/or TargetFrameworkVersion properties right???
If yes again, it would mean that just installing the latest framework (and also the older frameworks but not installing visual studio) in my Continuous Integration box, I could point to build always any solution to: %WINDIR%\Microsoft.NET\Framework\v4.0.30319\MsBuild.exe and just specify the ToolsVersion argument (if required, since each project can have its own target version specified in the TargetFrameworkVersion which it would cause to target an older .Net Framework version).
Following this I think my CI box would be building like Visual Studio does. Am I right? What am I missing? Is there a way to be completely sure?
I did a quick test, and I think it works :p the projects are being built according to the .Net Framework specified but like I said I want to be sure I am not missing anything.
Any thoughts?
BTW:
The simple reason to want to do that is because I have several custom MSBuild scripts that are reusable accross projects, but some of the functionality in these scripts require MSBuild 4.0 and also I have several MSBuild tasks built on top of the framework 4.0 so if I have for example a solution targetting the Framework 2.0 and I try to build it using: %WINDIR%\Microsoft.NET\Framework\v2.0.50727\MsBuild.exe I get MSBuild errors trying to load my custom targets
Yes, you've got it mostly correct. Calling MSBuild from the 4.0 directory will do the correct thing against previous versions. They only thing I wanted to add was that 3.5 must be on the box to actually build projects targeting 2.0, 3.0 and 3.5.
This page here: http://msdn.microsoft.com/en-us/library/bb822049.aspx calls out the what versions Windows comes with what version of the framework pre-installed.
I just starting to use Visual Studio 2010 and .NET 4.0. I created a new WPF project a DLL built for .NET 2.0. When I build the project, I get a bunch of warnings like this one:
The referenced assembly
"MicroFour StrataFrame Business...processorArchitecture=MSIL"
could not be resolved because it has a dependency on
"System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
which is not in the currently targeted framework ".NETFramework,Version=v4.0,Profile=Client".
Please remove references to assemblies not in the targeted framework
or consider retargeting your project.
When I reference a project I created that targets 3.5, it can't find any of the namespaces (during compile), though they show up in the object browser and intellisense correctly shows them.
Is there something I'm missing that needs to be done to reference an older .NET assembly?
There is very little point in targeting the client profile for .NET 4.0. The download is 41MB, the full version is 48MB, only 15% bigger. Unfortunately it is the default in VS2010, just change it with Project + Properties, Application tab, Target framework combo.
The client profile does make a lot of sense if you target 3.5, the full install is ~350 MB. The huge difference is explained by the prerequisites, .NET 4.0 requires at least XP SP3 or Vista SP1. But 3.5 installs on any version of Windows > 2000. The 3.5 installer thus contains lots of the required updates for unmanaged Windows components used by .NET. The web installer lessens that blow considerably btw.
Your 2.0 assembly has a reference to System.Web. The reference is being automatically forwarded to your target framework, 4.0. So it is attempting to use System.Web, version 4.0.0.0. The problem is with 4.0 (actually this started with 3.5), there is now the notion of a client profile. The client profile has a smaller set of reference assemblies, anything web/server related has been removed. This is to make the .NET framework a smaller/simpler download for end users.
With VS 2010 and .NET 4, the client profile is being pushed a lot harder, MS really wants us to use it. So your .NET 4 project is targeting the client profile by default. Your referenced assembly wants System.Web, so in that case you need to switch to the full profile.