Tiered compilation can mess up the assembler output when doing optimization work. Is there any way to disable it to get the high-quality output assembler without the need to pre-heat the method?
Adding this to your project should work too.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TieredCompilation>false</TieredCompilation>
</PropertyGroup>
</Project>
To disable the tiered compilation for the CoreCLR for all projects set the relevant environment variable:
set COMPlus_TieredCompilation=0
You can set it up for the machine to disable it altogether or set it immediately before you call your executable to have it disabled temporarily.
Related
Unable to create packages for a Dot Net Core project using 4.7 framework. I am using msbuild /t:pack /p:COnfiguration=Release command in teamcity to create a package.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net471</TargetFramework>
</PropertyGroup>
</Project>
NuGet.Build.Tasks.Pack is installed in the project.
we use only .net core csproj structure but not .net core as target framework so it can't be compiled via .net CLI - that's why we build projects via MSBuild and not .net CLI
Please guide how to create packages for such project.
Seems that the way TeamCity operates with msbuild, by default it creates a wrapper script and then calls that. Something in the way the wrapper opperates prevents it from working properly.
At the TeamCity MSBUILD Docs there is a note on Implementation Note that you can disable the wrapper. I tried this and it seemed like it works.
To disable the wrapper behaviour teamcity.msbuild.generateWrappingScript to false.
I did this by adding teamcity.msbuild.generateWrappingScript as a configuration parameter on the build config with the value "false". Then I re-ran the build and it behaved as expected.
I'm currently working on a Xamarin.Forms project named ABCD, using macOS Sierra v10.12.6 and Visual Studio (VS) for Mac v7.3.2 (the set up steps are detailed here).
Having successfully set that up, I continue as follows:
Right-clicking the main project folder, I select Options.
Under Build, in General, under Target Framework: .NET Portable: PCL 4.5 - Profile111 has been automatically selected for me.
I switch this to the option right above it: .NET Standard Platform: netstandard1.5; then select OK.
After switching this framework, I rebuild the project. After the rebuild, a warning appears:
Warning MSB3276: Found conflicts between different versions of the same dependent assembly. Please set the "AutoGenerateBindingRedirects" property to true in the project file. For more information, see http://go.microsoft.com/fwlink/?LinkId=294190. (MSB3276) (ABCD.iOS)
So maybe this is because the NETStandard.Library package is out-of-date.
In the main Packages folder, right-clicking NETStandard.Library says version 1.6.0, but typing dotnet --version into Terminal shows 2.1.3, so I update NETStandard.Library in VS – accept the licenses that come up.
Same warning still in place after rebuilding.
So I go to the Microsoft link provided by the warning and follow their instructions to add <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects> to the various .csproj files.
I added this to the main .csproj file, rebuilt the project and got the same warning.
I added this to both the iOS and Android .csproj files, rebuilt the project and got the same warning.
So what's this problem, why is it so persistent, and how much trouble will it give me down the road if I just ignore it?
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
My experience was that we need <AutoGenerateBindingRedirects> to be true.
My Dev Environment:
macOS Mojave 10.14.2 (18C54)
VisualStudio for Mac Professional Version 7.7.4 (Build 1)
#Solution:
What I did is followed the instructions as given in following MS Doc(link).
Unload the MyBeautifulApp.Xamarin.iOS.csproj from the Visual Studio Xamarin Forms solution.
Edit the MyBeautifulApp.Xamarin.iOS.csproj file manually using TextEdit and add the following line
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
to the PropertyGroup which is related to your Build Config which you were trying to build and was giving the error.
Save the .csproj file. Then close the file and reload the Project in your VS Solution Explorer.
Then clean and try to build, and it should successfully build without giving any warnings or errors. -----> For me this worked.
Note: I edited the .csproj file of my Xamarin.Forms iOS App project only. Because Android project which was within the Xamarin.Forms solution were already built successfully.
After editing my MyBeautifulApp.Xamarin.iOS.csproj file manually it looked like following:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">iPhoneSimulator</Platform>
<ProductVersion>8.0.30703</ProductVersion>
<SchemaVersion>2.0</SchemaVersion>
<ProjectGuid>{asdf-7AC6-asdf-9890-asdf}</ProjectGuid>
<ProjectTypeGuids>{asdfasd-340asdf5-455asdfC-asdf-asdf};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
<TemplateGuid>{6143fdea-f3c2-4a09-aafa-6e230626515e}</TemplateGuid>
<OutputType>Exe</OutputType>
<RootNamespace>MyBeautifulApp.Xamarin.iOS</RootNamespace>
<IPhoneResourcePrefix>Resources</IPhoneResourcePrefix>
<AssemblyName>MyBeautifulApp.Xamarin.iOS</AssemblyName>
<MtouchHttpClientHandler>NSUrlSessionHandler</MtouchHttpClientHandler>
<NuGetPackageImportStamp>
</NuGetPackageImportStamp>
**<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>**
</PropertyGroup>
<PropertyGroup>
....For another build configuration related property group...
Further More: The question now I have is should I do this change for all the other PropertyGroups of that .iOS.csproj file which are related to other Build configurations? I would be glad to know from someone out there. But for now I have decided not to touch those until it gives me a warning/error in the future.
Hope this will be helpful to anybody out there.
Finally fixed this warning, and the solution was rather counterintuitive.
Despite the warning saying specifically "Please set the "AutoGenerateBindingRedirects" property to true in the
project file", the warning will only go away if you change <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects> to <AutoGenerateBindingRedirects>false</AutoGenerateBindingRedirects>.
I created a .NET Core application (v1.1) in Visual Studio 2017. When I compile it, I get a DLL file produced instead of the expected EXE file for the built project. I did check the csproj file and confirmed the output type is set to exe, but no dice.
Why is Visual Studio 2017 is still producing a DLL file?
I'm sure it's a quick setting somewhere that I forgot...
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp1.1</TargetFramework>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
<PlatformTarget>AnyCPU</PlatformTarget>
</PropertyGroup>
<ItemGroup>
<ProjectReference Include="..\Core.EF.SqlServer\Core.EF.SqlServer.csproj" />
</ItemGroup>
</Project>
Update 2019:
.NET Core 3.0+ projects will now include an executable for the platform you build on by default. This is just a shim executable and your main logic is still inside a .dll file.
But .NET Core 3.0 also introduced single-file deployments so deploying with
dotnet publish -r win-x64 -p:PublishSingleFile=True --self-contained false
will create a single .exe file containing all your dependencies. You can change --self-contained to true to also include the .NET Core Runtime as well so .NET Core does not need to be installed globally on the target machine.
Original
.NET Core applications are supposed to be .dllfiles. OutputType set to Exe in this case means "executable" and does everything necessary to ensure that the output is runnable (entry point from Main() method, .runtimeconfig.json file). The resulting DLL file is meant to be run using:
dotnet yourapp.dll
This DLL file works across all platforms that are supported by the .NET Core runtime (Windows, Linux, and macOS). This is called a "portable" or "framework dependent" deployment.
If you want really a .exe file, consider self-contained deployments. This will create an output that contains its own copy of the .NET Core runtime and an yourapp.exe file - but it also increases the size of the published application and it needs to be updated when new versions of the runtime are released.
Also, the resulting application only works on the operating system published for.
Refer to .NET Core application deployment for more details on the deployment options and how to set them up.
In Visual Studio 2017:
Right click on your project and select Publish (In Visual Studio 2019, click on menu Build → Publish <projectName>)
Select 'Folder' and create a new profile
In tab 'Publish', click 'Configure...'
Select Deployment Mode: Self-contained, Target Runtime: win-x86 (or win-x64)
Save
Publish
In the folder <Your project>\bin\Debug\netcoreapp2.1\win-x86\ you will see the EXE file:
Starting with .NET Core 2.2 you can build framework-dependent executables
Although building a self-contained deployment can be a good solution, it has its own drawbacks. (See R.Titov and Martin Ullrichs' answers on SCD-s.)
Fortunately, .NET Core 2.2 supports the building of so called framework-dependent executable-s, that are essentially a wrapper binary (.exe on Windows) around the standard dll-s.
This way you have all the advantages (and disadvantages) of the standard framework-dependent deployment (again, see Martin's answer), but you have a convenient way to launch it, without having to call it through the dotnet CLI.
You can publish your app as a Framework-Dependent Executable using the following syntax:
dotnet publish -c Release -r <RID> --self-contained false
Where RID is the usual runtime identifier, e.g. win-x64 or whatever platform you wish to build for (see the catalog here).
That's how you do a self-contained publish with command-line in any OS:
dotnet publish C:\src\App\App.csproj -c release -r win-x64 -o output-win-x64
Besides, you might want to get the output decreased from typical ~60 MB for a simple Hello World app to ~30 MB by using ILLink.
Also, you might want to go further and get a single .exe file of a size at around 5 MB and use ILCompiler. See this reply.
The other answers are good, but what I find sometimes convenient is:
Not have it self-contained because the target machine is likely to have .NET Core of the correct version installed. This cuts on number of the DLL files I need to ship.
Not have to specify dotnet on the command line
For this, a bat file wrapper can be used, similar to these lines:
#ECHO OFF
REM see http://joshua.poehls.me/powershell-batch-file-wrapper/
SET SCRIPTNAME=%~d0%~p0%~n0.dll
SET ARGS=%*
dotnet "%SCRIPTNAME%" %ARGS%
EXIT /B %ERRORLEVEL%
If your application ends up in yourapp.dll, name the bat file yourapp.bat and place it along side the DLL file. Now instead of dotnet yourapp.dll params you can call yourapp params.
Note that the context of this answer is in-house tooling, so all the developers using the utility will have a pretty standard development machine setup. If this is to be distributed to an external customer who is running who knows what on their boxes, the self-contained option is far superior.
For a Visual Studio projects such as a ASP.NET MVC5, how do you disable compiling of TypeScript files on build/debug?
I currently have tsconfig.json compileOnSave and buildOnSave set to false. Does something need to be added to the projects .csproj to ensure it isn't compiled?
When debugging the ASP.NET MVC5 project, it compiles all .ts files.
Thank you for any help you can provide.
Add the property <TypeScriptCompileBlocked>true</TypeScriptCompileBlocked> to a PropertyGroup in your csproj file (I added it under the Configuration label). This should disable all msbuild based TS compilation.
With this setting enabled you shouldn't need the tsconfig.json settings compileOnSave/buildOnSave.
If you are on an older version of Visual Studio (I had implicitly thought about VS 2017 or xproj with 2015), the property may be <TypeScriptEnabled>false</TypeScriptEnabled>.
I had all of this configured, but it still did not fix the issue
(in visual studio 2019).
I added additionally this:
<TypeScriptCompileOnSaveEnabled>False</TypeScriptCompileOnSaveEnabled>
and restarted the visual studio. After that, it started working for me.
None of the other solutions worked for me and this one caused an error on project load (VS 2019 - 16.9.4)
<TypeScriptCompileBlocked>true</TypeScriptCompileBlocked> // doesn't work for me
Another way of doing the same thing (albeit with very minor overhead) is to just remove all your TS from the compilation index.
<TypeScriptCompile Remove="*" />
I use this for avoiding compilation of node modules, like so:
<TypeScriptCompile Remove="node_modules\**" />
For Visual Studio 2015, adding below line under PropertyGroup helped me.
<TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>
I had this issue, tested all the things that was posted here without success,
But after adding this, things worked:
<TypeScriptToolsVersion>3.9</TypeScriptToolsVersion>
Seems like the version that I was using did compile no matter the settings.
Next approach worked for me (.NET 6, VS2022, ASP.NET Core + Angular project).
Add this setting to your *.csproj file:
<PropertyGroup>
<TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>
</PropertyGroup>
I'm using OpenCover to generate test coverage reports for my projects, but it's not generating any data. Checking in my logs, it's showing "missing pdb" for the dlls in question, however the pdbs are available in the same directory.
Things I've tried:
I've tried adding the directories with the pdbs in explicitly using the -searchdirs option - makes no difference.
I've checked and it looks like XUnit doesn't do shadow copying of dlls, so they are being accessed from the right directory. The opencover results.xml backs me up on this.
I'm using a command line of
opencover.console -oldstyle -register:user
-target:"C:\Program Files\Dotnet\dotnet.exe"
-targetargs:"test"
-searchdirs:"C:\dev\public\hermes-c#\Hermes.Server\Hermes.AspNetCore.Test\bin\Debug\netcoreapp1.0"
Any and all thoughts appreciated!
.NET Core uses a "Portable PDB" format by default, which OpenCover does not understand yet.
Try the following build options instead:
"buildOptions": {
"debugType": "full"
},
Note: when using full the generated debug symbols are for Windows only...
Update: with MSBuild based projects this becomes:
<PropertyGroup>
<DebugType>full</DebugType>
</PropertyGroup>
And, we're able to build using the /p:DebugType=Full switch too. Thus, the "ordinary" build can use the default debug setting, but a "special" build for coverage analysis can change that to full.