aelij / IgnoresAccessChecksToGenerator

Generates reference assemblies where all the internal types & members become public, and applies the IgnoresAccessChecksTo attribute
MIT License
167 stars 21 forks source link

Should InternalsAssemblyNames be an MSBuild Item, not a Property? #3

Closed KirillOsenkov closed 1 year ago

KirillOsenkov commented 6 years ago

It feels like it's better to use an MSBuild item to represent multiple values, this way it's perhaps more straightforward and you don't need to muck with semicolon separated lists.

aelij commented 6 years ago

Yeah, I did use items at first, but they appeared in VS as files. I tried looking up how to make them not visible, but couldn't find a way.

weltkante commented 6 years ago

What tag did you use for the items? The item type is defined by the items tag name and if you just use a tag name not known to VS you should be fine.

aelij commented 6 years ago

I used something like InternalsAssemblyName. I don't think there's a chance it's a known tag.

weltkante commented 6 years ago

Hmm, you are right, custom items in the main csproj indeed show up in the solution explorer. Never noticed that before because I'm doing all my customization in a secondary targets file, but thats probably not applicable here.

I can find workarounds like setting an InProject=false or Visible=false attribute on the item (both seem to work), not sure if that has other negative effects. It would be nicer if one could declare an item type to be hidden by default.

aelij commented 6 years ago

@KirillOsenkov is an MSBuild expert, maybe he'll know :)

aelij commented 6 years ago

Hmm, adding an ItemDefinition in the targets file might work:

<ItemDefinitionGroup>  
    <InternalsAssemblyName> 
        <Visible>false</Visible>
    </InternalsAssemblyName>
</ItemDefinitionGroup>  

I'll give it a try when I get a chance.

KirillOsenkov commented 6 years ago

Yes, that should work.

aelij commented 1 year ago

Fixed in cf3816a