Version Used: .Net Core 2.0.0
Steps to Reproduce:
Create the following .Net Core 2.0 application:
csproj:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.0</TargetFramework>
<GenerateAssemblyInfo>False</GenerateAssemblyInfo>
</PropertyGroup>
</Project>
Program.cs:
```c#
using System;
using System.Reflection;
[assembly: AssemblyVersion("1.0.*")]
class Program
{
static void Main()
{
Console.WriteLine(typeof(Program).Assembly.GetName().Version);
}
}
```
dotnet buildActual Behavior: dotnet build produces a confusing error message:
Program.cs(4,28): error CS7034: The specified version string does not conform to the required format - major[.minor[.build[.revision]]]
Expected Behavior: The error clearly explains that the actual problem is that wildcard assembly versions are not allowed for deterministic builds.
Adding <Deterministic>False</Deterministic> to the csproj indeed makes the code compile.
The question that prompted this issue: https://github.com/dotnet/sdk/issues/1098#issuecomment-335409662.
The existing error message is quite uninformative, I would imagine using wildcards is fairly common so it would be great to see this error message detail some of the information found here.
Even more confusing in my case is I am simply using the new csproj format and targeting 461 (as I was previously) so you would not expect a change in behavior here.
+1
The message should also provide a link, explaining why deterministic is considered a desired setting, e.g.
http://blog.paranoidcoding.com/2016/04/05/deterministic-builds-in-roslyn.html
and Compilers should be deterministic: same inputs generate same outputs聽#372
I agree. Queue a fix (https://github.com/dotnet/roslyn/pull/22973).
Thanks for the feedback.
Most helpful comment
The existing error message is quite uninformative, I would imagine using wildcards is fairly common so it would be great to see this error message detail some of the information found here.
Even more confusing in my case is I am simply using the new csproj format and targeting 461 (as I was previously) so you would not expect a change in behavior here.
+1