Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't reference AssemblyMetadataAttribute in generated AssemblyInfo.cs when targeting net40 #11862

Closed
halter73 opened this issue Jun 3, 2020 · 14 comments · Fixed by #12073
Closed
Assignees
Labels
Milestone

Comments

@halter73
Copy link
Member

halter73 commented Jun 3, 2020

The ef6 build targeting net40 failed recently with the following error after updating the .NET SDK to 5.0.100-preview.6.20266.3.

##[error]artifacts\obj\ef6\Release\net40\ef6.AssemblyInfo.cs(21,30): error CS0234: (NETCORE_ENGINEERING_TELEMETRY=Build) The type or namespace name 'AssemblyMetadataAttribute' does not exist in the namespace 'System.Reflection' (are you missing an assembly reference?)

dotnet/ef6#1678

AssemblyMetadataAttribute doesn't exist in net40. ef6 has an AssemblyMetadataAttribute polyfill in some of its projects, but not the one that failed to build. Adding the polyfil works around the issue.

It looks like this is a regression introduced by #11559 and could be fixed by not generating a reference to AssemblyMetadataAttribute when targeting net40.

@dougbu
Copy link
Member

dougbu commented Jun 6, 2020

/cc @sfoslund @dsplaisted @wli3

@sfoslund sfoslund added this to the 5.0.1xx milestone Jun 8, 2020
@sfoslund sfoslund self-assigned this Jun 8, 2020
@sfoslund
Copy link
Member

sfoslund commented Jun 8, 2020

@wli3 @dsplaisted is not defining AssemblyMetadataAttribute a special case with net40 or is this a more common case?

@sfoslund
Copy link
Member

Ping @wli3 @dsplaisted, is AssemblyMetadataAttribute only undefined with net40?

@dsplaisted
Copy link
Member

It was introduced in .NET 4.5. So if the TargetFrameworkIdentifier is .NETFramework and the version is less than 4.5, we should not emit this.

FYI @clairernovotny @tmat, looks like we won't get the RepositoryUrl in the assembly metadata for projects targeting .NET 4.0.x or earlier.

@tmat
Copy link
Member

tmat commented Jun 15, 2020

@clairernovotny Perhaps we should require packages to have implementation assemblies for netstandard, netcoreapp or net45+ and not validate libraries that target earlier frameworks.

@clairernovotny
Copy link
Member

clairernovotny commented Jun 15, 2020

@tmat Not really sure why this matters? What do we need this attribute in the assembly for other than informational use? The thing we actually check is in the PDB.

@tmat
Copy link
Member

tmat commented Jun 15, 2020

@clairernovotny We would use this URL to clone the sources when validating reproducibility. The info in the PDB does not include URL that can be cloned. It provides content URL pattern for each file. I guess another approach would be to fall back to downloading each file separately if the clone URL is not available. Less efficient, but perhaps ok as a fall back.

@clairernovotny
Copy link
Member

@tmat I guess I assumed that we'd just download each file. There's no guarantee the repo format is Git either, and no need for it to be long as we can download the files via the URL.

@tmat
Copy link
Member

tmat commented Jun 17, 2020

@clairernovotny I suspect that will be much slower than clone. But certainly something to try and measure.

@heng-liu
Copy link
Contributor

Hi @sfoslund ,
We have a project referencing AssemblyMetadataAttribute in generated AssemblyInfo.cs when targeting net40. May I know if there is any workaround if using public preview5? Thanks!

@sfoslund
Copy link
Member

@heng-liu sure, you can set the PublishRepositoryUrl property to false and not set the RepositoryUrl property for now. It should be fixed in the next preview.

@heng-liu
Copy link
Contributor

Thanks! @sfoslund

@sharwell
Copy link
Member

sharwell commented Jul 1, 2020

@sfoslund What version was this fixed in?

@sfoslund
Copy link
Member

sfoslund commented Jul 1, 2020

@sharwell It should be in preview 7

jaredpar added a commit to jaredpar/roslyn that referenced this issue Jul 22, 2020
This is necessary for us to test features like covariant returns because
we need to be able to target `net5.0` in our unit test projects.

Issues encountered in this update:

- WinRT is no longer supported in .NET 5. As a result we no longer multi-target
.NET Core in our WinRT test assembly as well as having to disabling a
few WinRT tests in others.  dotnet/runtime#37672
- Change our Debugger Proxy tests to react to a runtime change
dotnet/runtime@c362923
- Work around .NET5 P6 bug dotnet/sdk#11862
jaredpar added a commit to dotnet/roslyn that referenced this issue Jul 22, 2020
* Move to the .NET 5 SDK

This is necessary for us to test features like covariant returns because
we need to be able to target `net5.0` in our unit test projects.

Issues encountered in this update:

- WinRT is no longer supported in .NET 5. As a result we no longer multi-target
.NET Core in our WinRT test assembly as well as having to disabling a
few WinRT tests in others.  dotnet/runtime#37672
- Change our Debugger Proxy tests to react to a runtime change
dotnet/runtime@c362923
- Work around .NET5 P6 bug dotnet/sdk#11862
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants