Description of problem: Since the 1.0.1 dotnet core release we see strange compilation failures for a Hello World project (dotnet new). This only happens when the project directory in which "dotnet new/restore/run" is invoked in the current user's $HOME directory. It's easiest to reproduce if one creates a new user for the purpose of reproducing. Version-Release number of selected component (if applicable): $ rpm -q rh-dotnetcore10-dotnetcore rh-dotnetcore10-dotnetcore-1.0.1-2.el7.x86_64 How reproducible: 100% Steps to Reproduce: $ echo $HOME /home/dotnet-test $ pwd /home/dotnet-test $ scl enable rh-dotnetcore10 bash $ dotnet new $ dotnet restore $ dotnet run Actual results: "dotnet run" fails to compile with a slew of errors/warnings. Here is a trail: [...] /home/dotnet-test/.nuget/packages/System.Threading.Overlapped/4.0.1/src\src/System.Threading.Overlapped/ref/System.Threading.Overlapped.cs(40,28): warning CS3021: 'ThreadPoolBoundHandle.FreeNativeOverlapped(NativeOverlapped*)' does not need a CLSCompliant attribute because the assembly does not have a CLSCompliant attribute /home/dotnet-test/.nuget/packages/System.Threading.Overlapped/4.0.1/src\src/System.Threading.Overlapped/src/System/Threading/ClrThreadPoolBoundHandle.cs(278,37): warning CS3021: 'ThreadPoolBoundHandle.GetNativeOverlappedState(NativeOverlapped*)' does not need a CLSCompliant attribute because the assembly does not have a CLSCompliant attribute /home/dotnet-test/.nuget/packages/System.Threading.Overlapped/4.0.1/src\src/System.Threading.Overlapped/src/System/Threading/Win32ThreadPoolBoundHandle.cs(144,37): warning CS3021: 'ThreadPoolBoundHandle.GetNativeOverlappedState(NativeOverlapped*)' does not need a CLSCompliant attribute because the assembly does not have a CLSCompliant attribute /home/dotnet-test/.nuget/packages/System.Threading.Overlapped/4.0.1/src\src/System.Threading.Overlapped/ref/System.Threading.Overlapped.cs(42,37): warning CS3021: 'ThreadPoolBoundHandle.GetNativeOverlappedState(NativeOverlapped*)' does not need a CLSCompliant attribute because the assembly does not have a CLSCompliant attribute /home/dotnet-test/.nuget/packages/System.Threading.Overlapped/4.0.1/src\src/System.Threading.Overlapped/src/System/Threading/ClrThreadPoolPreAllocatedOverlapped.cs(51,23): warning CS3021: 'PreAllocatedOverlapped.PreAllocatedOverlapped(IOCompletionCallback, object, object)' does not need a CLSCompliant attribute because the assembly does not have a CLSCompliant attribute /home/dotnet-test/.nuget/packages/System.Threading.Overlapped/4.0.1/src\src/System.Threading.Overlapped/src/System/Threading/Win32ThreadPoolPreAllocatedOverlapped.cs(15,23): warning CS3021: 'PreAllocatedOverlapped.PreAllocatedOverlapped(IOCompletionCallback, object, object)' does not need a CLSCompliant attribute because the assembly does not have a CLSCompliant attribute /home/dotnet-test/.nuget/packages/System.Threading.Overlapped/4.0.1/src\src/System.Threading.Overlapped/ref/System.Threading.Overlapped.cs(26,16): warning CS3021: 'PreAllocatedOverlapped.PreAllocatedOverlapped(IOCompletionCallback, object, object)' does not need a CLSCompliant attribute because the assembly does not have a CLSCompliant attribute /home/dotnet-test/.nuget/packages/System.Threading.Overlapped/4.0.1/src\src/System.Threading.Overlapped/src/System/Threading/IOCompletionCallback.cs(8,33): warning CS3021: 'IOCompletionCallback' does not need a CLSCompliant attribute because the assembly does not have a CLSCompliant attribute /home/dotnet-test/.nuget/packages/System.Threading.Overlapped/4.0.1/src\src/System.Threading.Overlapped/ref/System.Threading.Overlapped.cs(13,33): warning CS3021: 'IOCompletionCallback' does not need a CLSCompliant attribute because the assembly does not have a CLSCompliant attribute /home/dotnet-test/.nuget/packages/System.Runtime/4.1.0/src\src/System.Runtime/ref/System.Runtime.cs(2890,16): warning CS3021: 'DecimalConstantAttribute.DecimalConstantAttribute(byte, byte, uint, uint, uint)' does not need a CLSCompliant attribute because the assembly does not have a CLSCompliant attribute /home/dotnet-test/.nuget/packages/System.Runtime.InteropServices/4.1.0/src\src/System.Runtime.InteropServices/ref/System.Runtime.InteropServices.cs(707,22): warning CS3021: 'SafeBuffer.ByteLength' does not need a CLSCompliant attribute because the assembly does not have a CLSCompliant attribute /home/dotnet-test/.nuget/packages/System.Runtime.InteropServices/4.1.0/src\src/System.Runtime.InteropServices/ref/System.Runtime.InteropServices.cs(709,28): warning CS3021: 'SafeBuffer.AcquirePointer(ref byte*)' does not need a CLSCompliant attribute because the assembly does not have a CLSCompliant attribute /home/dotnet-test/.nuget/packages/System.Runtime.InteropServices/4.1.0/src\src/System.Runtime.InteropServices/ref/System.Runtime.InteropServices.cs(711,21): warning CS3021: 'SafeBuffer.Initialize(uint, uint)' does not need a CLSCompliant attribute because the assembly does not have a CLSCompliant attribute /home/dotnet-test/.nuget/packages/System.Runtime.InteropServices/4.1.0/src\src/System.Runtime.InteropServices/ref/System.Runtime.InteropServices.cs(713,21): warning CS3021: 'SafeBuffer.Initialize(ulong)' does not need a CLSCompliant attribute because the assembly does not have a CLSCompliant attribute /home/dotnet-test/.nuget/packages/System.Runtime.InteropServices/4.1.0/src\src/System.Runtime.InteropServices/ref/System.Runtime.InteropServices.cs(715,21): warning CS3021: 'SafeBuffer.Initialize<T>(uint)' does not need a CLSCompliant attribute because the assembly does not have a CLSCompliant attribute /home/dotnet-test/.nuget/packages/System.Runtime.InteropServices/4.1.0/src\src/System.Runtime.InteropServices/ref/System.Runtime.InteropServices.cs(717,18): warning CS3021: 'SafeBuffer.Read<T>(ulong)' does not need a CLSCompliant attribute because the assembly does not have a CLSCompliant attribute /home/dotnet-test/.nuget/packages/System.Runtime.InteropServices/4.1.0/src\src/System.Runtime.InteropServices/ref/System.Runtime.InteropServices.cs(719,21): warning CS3021: 'SafeBuffer.ReadArray<T>(ulong, T[], int, int)' does not need a CLSCompliant attribute because the assembly does not have a CLSCompliant attribute /home/dotnet-test/.nuget/packages/System.Runtime.InteropServices/4.1.0/src\src/System.Runtime.InteropServices/ref/System.Runtime.InteropServices.cs(722,21): warning CS3021: 'SafeBuffer.Write<T>(ulong, T)' does not need a CLSCompliant attribute because the assembly does not have a CLSCompliant attribute /home/dotnet-test/.nuget/packages/System.Runtime.InteropServices/4.1.0/src\src/System.Runtime.InteropServices/ref/System.Runtime.InteropServices.cs(724,21): warning CS3021: 'SafeBuffer.WriteArray<T>(ulong, T[], int, int)' does not need a CLSCompliant attribute because the assembly does not have a CLSCompliant attribute /home/dotnet-test/.nuget/packages/System.Reflection.Emit.ILGeneration/4.0.1/src\src/System.Reflection.Emit.ILGeneration/ref/System.Reflection.Emit.ILGeneration.cs(48,21): warning CS3021: 'ILGenerator.Emit(OpCode, sbyte)' does not need a CLSCompliant attribute because the assembly does not have a CLSCompliant attribute /home/dotnet-test/.nuget/packages/System.Runtime.Loader/4.0.0/src\src/System.Runtime.Loader/ref/System.Runtime.Loader.cs(14,35): warning CS3021: 'AssemblyExtensions.TryGetRawMetadata(Assembly, out byte*, out int)' does not need a CLSCompliant attribute because the assembly does not have a CLSCompliant attribute Compilation failed. 47807 Warning(s) 17005 Error(s) Time elapsed 00:00:23.6626982 Expected results: "dotnet run" compiles fine and "Hello World" gets printed correctly after. Like this: [dotnet-test@rhel7 ~]$ dotnet run Project dotnet-test (.NETCoreApp,Version=v1.0) will be compiled because expected outputs are missing Compiling dotnet-test for .NETCoreApp,Version=v1.0 Compilation succeeded. 0 Warning(s) 0 Error(s) Time elapsed 00:00:01.9247373 Hello World! Additional info: Downgrading to rh-dotnetcore10-dotnetcore-1.0.0-7.el7.x86_64 seems to fix the issue. See also bug 1377808 where we've discovered this issue.
This does not happen on Microsoft's builds of .NET Core 1.0.1 (https://www.microsoft.com/net/core#centos).
The way 'dotnet build' works is that it looks for all source code under the current directory and then builds it (ignoring lots of other details). When it finds a bunch of .cs files somewhere under the current directory (which happens to include .nuget in this bug), it will try and compile them. The nuget archive contains many .cs files basically describing the standard API in terms of interfaces and method declarations. These .cs files have unexpected attributes (causes build warnings) and are abstract (causes build errors). 'dotnet build' sees these files, tries to compile them and runs into many errors and warnings. Looking at what Microsoft's binaries do, they do not put all these .cs files somewhere under .nuget. I don't know whether the .cs files are expected to be there or not. If the extra .cs files are a bug, we need to remove them. If they are supposed to be there, then not creating projects in $HOME is a design restriction imposted by the design of .NET Core.
Why does this work with 1.0.0 and not with 1.0.1, though?
Confirmed. Removing *.cs files in .nuget directory makes the reproducer work: $ echo $HOME /home/dotnet-test $ pwd /home/dotnet-test $ rm -rf .nuget $ scl enable rh-dotnetcore10 bash $ dotnet new $ dotnet restore $ find .nuget/ -name '*.cs' -print0 | xargs -0 rm $ dotnet run Project dotnet-test (.NETCoreApp,Version=v1.0) will be compiled because expected outputs are missing Compiling dotnet-test for .NETCoreApp,Version=v1.0 Compilation succeeded. 0 Warning(s) 0 Error(s) Time elapsed 00:00:01.4523527 Hello World!
(In reply to Severin Gehwolf from comment #3) > Why does this work with 1.0.0 and not with 1.0.1, though? 1.0.0 and 1.0.1 were built very differently. 1.0.0 was hand-assembled on my local machine, manually, using various Windows and RHEL VMs to build certain parts. Things like CoreFX were build on both Windows and RHEL and assembled in a particular order. Parts of CoreFX, for example, didn't work if built on RHEL. From what I can tell, this is how Microsoft builds 1.0.0 and 1.0.1 and other products. 1.0.1 was built completely on RHEL, using the new source-build infrastructure. Microsoft probably don't use this themselves. It seems to me that there's a bug in the source-build system or something in the .NET Core build scripts screws up when building on RHEL.
Looks like changing a '\' to '/ at https://github.com/dotnet/buildtools/blob/29b79c7a72ff03e8ab526f5663b99ce6fb2d58fe/src/Microsoft.DotNet.Build.Tasks.Packaging/src/PackageFiles/PackageLibs.targets#L182 when building corefx fixes the bug.
(In reply to Omair Majid from comment #6) > Looks like changing a '\' to '/ at > https://github.com/dotnet/buildtools/blob/ > 29b79c7a72ff03e8ab526f5663b99ce6fb2d58fe/src/Microsoft.DotNet.Build.Tasks. > Packaging/src/PackageFiles/PackageLibs.targets#L182 when building corefx > fixes the bug. What does Microsoft have to say about this?
msbuild is supposed to be platform agnostic and it should have handled / vs \ correctly. They are treating this as any other platform compatibility bug and are looking into the root cause and whether the suggested change breaks anything on Windows.
(In reply to Omair Majid from comment #8) > msbuild is supposed to be platform agnostic and it should have handled / vs > \ correctly. They are treating this as any other platform compatibility bug > and are looking into the root cause and whether the suggested change breaks > anything on Windows. Thanks. Is there an upstream issue we can link to?
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-2953.html