Skip to content

No-op on target frameworks that are already annotated#49

Closed
jnm2 wants to merge 1 commit into
tunnelvisionlabs:masterfrom
jnm2:no_op
Closed

No-op on target frameworks that are already annotated#49
jnm2 wants to merge 1 commit into
tunnelvisionlabs:masterfrom
jnm2:no_op

Conversation

@jnm2

@jnm2 jnm2 commented Oct 31, 2019

Copy link
Copy Markdown
Contributor

Superseded by #59

Also fixes #38.

Tested on my Shouldly branch with two target frameworks temporarily appended:

<TargetFrameworks>net451;netstandard1.3;netstandard2.0;netstandard2.1;netcoreapp3.0</TargetFrameworks>

Before, #38 was reproing. After, everything was as expected (annotation on only the first three).

Comment on lines +7 to +8
('$(TargetFrameworkIdentifier)' == '.NETStandard' AND $([System.Version]::Parse($(TargetFrameworkVersion.Substring(1)))) &gt;= $([System.Version]::Parse('2.1')))
OR ('$(TargetFrameworkIdentifier)' == '.NETCoreApp' AND $([System.Version]::Parse($(TargetFrameworkVersion.Substring(1)))) &gt;= $([System.Version]::Parse('3.0')))">

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Best I knew offhand, improvements welcome!

@sharwell

sharwell commented Oct 31, 2019

Copy link
Copy Markdown
Member

The main issue here is we don't actually want to no-op, because we still need to rewrite the reference assemblies to drop the attributes from #46. The removal itself is already implemented:

// Start by removing any prior attributes that need to be filtered out
for (int i = 0; i < provider.CustomAttributes.Count; i++)
{
if (IsExcludedAnnotation(provider, annotatedProvider, provider.CustomAttributes[i]))
{
provider.CustomAttributes.RemoveAt(i);
i--;
}
}

Are the netstandard2.1 reference assemblies annotated? I was expecting them to have the attribute in place, but not have the nullable annotations. Could be wrong though.

@jnm2

jnm2 commented Oct 31, 2019

Copy link
Copy Markdown
Contributor Author

The main issue here is we don't actually want to no-op, because we still need to rewrite the reference assemblies to drop the attributes from #46.

I am very scared. This is kind of like a hard fork then for anyone who uses this package. I'll do it if I have to but I really don't like it. My understanding was that this was only for when you can't use HashCode.

@jnm2

jnm2 commented Oct 31, 2019

Copy link
Copy Markdown
Contributor Author

Are the netstandard2.1 reference assemblies annotated? I was expecting them to have the attribute in place, but not have the nullable annotations. Could be wrong though.

Just tried it. They are not annotated, good catch.

@jnm2

jnm2 commented Oct 31, 2019

Copy link
Copy Markdown
Contributor Author

Closing because no_op is not a good branch name for the work that needs to be done.

@jnm2 jnm2 closed this Oct 31, 2019
@jnm2

jnm2 commented Oct 31, 2019

Copy link
Copy Markdown
Contributor Author

we still need to rewrite the reference assemblies to drop the attributes

What if there's a csproj flag for this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Targets try to evaluate GetDirectoryName('') and cause "path is not of a legal form" error (support netcoreapp3.0 and netstandard2.1)

2 participants