aelij/ignoresaccesscheckstogenerator

Generates reference assemblies where all the internal types & members become public, and applies the IgnoresAccessChecksTo attribute

IgnoresAccessChecksTo Generator (MSBuild)

The IgnoresAccessChecksToAttribute is the reverse of the InternalsVisibleToAttribute - it allows an assembly to declare assemblies whose internals would be visible to it. The attribute class isn't declared in the BCL but is recognized by the CLR (Desktop >= 4.6 and Core), i.e. you can declare it in your code and it would work.

Since there's currently no compiler support for this attribute (I've submitted a PR to Roslyn), this package can be used as a workaround. It generates reference assemblies where all the internal types & members become public, and adds a C# file with the attribute and its instances.

Usage

Just add the package and define InternalsAssemblyName items with the assemblies you need access to.

<Project Sdk="Microsoft.NET.Sdk">

  <ItemGroup>
    <InternalsAssemblyName Include="AssemblyToGrantAccessTo1" />
    <InternalsAssemblyName Include="AssemblyToGrantAccessTo2" />
    <InternalsAssemblyExcludeTypeName Include="Namespace.TypeName" />
  </ItemGroup>

  <ItemGroup>
    <PackageReference Include="IgnoresAccessChecksToGenerator" Version="0.7.0" PrivateAssets="All" />
  </ItemGroup>

</Project>

ignoresaccesscheckstogenerator's Issues

Doesn't work with WPF projects

We have tried using the tool with a WPF project (consuming an internal type from Roslyn) and it failed because MarkupCompilePass1 attempted to instantiate an attribute from the rewritten assembly. Since the rewriter deletes method bodies it fails.

We have spent some time trying to come up with a workaround but abandoning it for now. Hopefully one day we'll return and revisit this.

Thanks for the amazing tool!

Suggestion

When an assembly that we depend on has many other dependencies, then loading that assembly by this task may fail.

Wouldn't it be easier to add a new global InternalsVisibleTo attribute to the generated assembly that contains the name of our assembly?
Something like:

<InternalsAddAssembly Include="OurAssembly, PublicKey=0123456......ABCDEF"/>

This should generate

[assembly: InternalsVisibleTo("OurAssembly, PublicKey=0123456......ABCDEF"")]

Does not open access to private methods

Hi I was trying this out on Strathweb.Samples.CSharp.NoVisibilityChecks and it works for classes but I can't get it to work with the private method Calculate().

Shouldn't it work there also?

.NET Core 2 Release giving IgnoresAccessChecksToGenerator.targets(12,5): error MSB4044: The "PublicizeInternals" task was not given a value for the required parameter "AssemblyNames".

unknown build error

I get the following error by using the nuget in a wpf net framework 4.8 project

error MC1000: Unknown build error, 'Could not load type 'System.Runtime.CompilerServices.RestrictedInternalsVisibleToAttribute' from assembly 'Microsoft.CodeAnalysis.Workspaces, Version=3.9.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' because the method '.ctor' has no implementation (no RVA).'

Monodevelop: analyzer uses original reference instead of generated one

Building works flawlessly, but monodevelop seems to use original reference for analyzer (auto completion etc.).
Is there a way to solve it automatically in project files without manually change reference after generation?
Or did I miss something?

In .csproj:

    <InternalsAssemblyNames>Assembly-CSharp;</InternalsAssemblyNames>
...
    <Reference Include="Assembly-CSharp">
      <HintPath>path\to\original\Assembly-CSharp.dll</HintPath>
    </Reference>

(I have little knowledge of around .csproj and .net build flow)

Maybe remove old Generated Assemblys on clean of project/solution

Don't know if this is possible, but I had an error with it.

see: roslynpad/roslynpad#414

System.ArgumentException: An item with the same key has already been added.

I got this when trying to gain access to Roslyn api...

Microsoft.CodeAnalysis.Features;Microsoft.CodeAnalysis.Workspaces

can be reproduced with this commit of avalonstudio...

https://github.com/VitalElement/AvalonStudio/tree/roslyn-access-without-sign

Severity	Code	Description	Project	File	Line	Suppression State
Error	MSB4018	The "GenerateDepsFile" task failed unexpectedly.
System.ArgumentException: An item with the same key has already been added.
   at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
   at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
   at Microsoft.NET.Build.Tasks.SingleProjectInfo.CreateProjectReferenceInfos(IEnumerable`1 referencePaths, IEnumerable`1 referenceSatellitePaths)
   at Microsoft.NET.Build.Tasks.GenerateDepsFile.ExecuteCore()
   at Microsoft.NET.Build.Tasks.TaskBase.Execute()
   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
   at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()	AvalonStudio.Projects.OmniSharp	C:\Program Files\dotnet\sdk\2.0.0-preview2-006497\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.targets	109	

Error "Could not load file or assembly ***" when I use it in console app (but it works in tests project)

When I use it in nunit tests project then it works right.
But when I use it in console project then I'm getting error: "Could not load file or assembly ***".
What's wrong?

Add supports F#

How to usage https://github.com/aelij/IgnoresAccessChecksToGenerator#usage

The file extension of 'obj\GeneratedPublicizedAssemblies\IgnoresAccessChecksTo.cs' is not recognized. Source files must have extension .fs, .fsi, .fsx, .fsscript, .ml or .mli.

Should InternalsAssemblyNames be an MSBuild Item, not a Property?

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.

[Feature Request] Add `<autogenerated />` comment to generated file header

When some code analyzer rules are enabled. (e.g. IDE0073: Require file header)
Warnings are reported on generated IgnoresAccessChecksTo.cs file.

It may be better to add the following comment to the IgnoresAccessChecksTo.cs header to suppress code analyzer related warnings.

// <auto-generated />

internal properties

Friends, is there any reason you have not included internal properties to make them public?

I modified the code on my own machine by adding the following to the CreatePublicAssembly method's inner loop

        foreach(var prop in type.Properties)
        {
            if (prop.GetMethod != null)
            {
                if ( prop.GetMethod.IsAssembly || 
                     prop.GetMethod.IsFamilyOrAssembly || 
                     prop.GetMethod.IsFamilyAndAssembly)
                {
                    prop.GetMethod.IsPublic = true;
                }
            }
            if (prop.SetMethod != null)
            {
                if (prop.SetMethod.IsAssembly ||
                     prop.SetMethod.IsFamilyOrAssembly ||
                     prop.SetMethod.IsFamilyAndAssembly)
                {
                    prop.SetMethod.IsPublic = true;
                }
            }
        }         

Is it possible to add it to the package?

Incremental build issues with IgnoresAccessChecksTo.cs

Looks like IgnoresAccessChecksTo.cs is being written to every time, even if the file already exists and the contents is identical:
https://github.com/aelij/IgnoresAccessChecksToGenerator/blob/9944e7715ae367a6a1a4a59359fbe0cedd7e579d/src/IgnoresAccessChecksToGenerator.Tasks/PublicizeInternals.cs#L113C50-L113C50

Would it make sense to check the file for existence first, and if it exists, read the text, and compare, and write only if different?

I'm seeing projects build every time because the input IgnoresAccessChecksTo.cs was written later than any of the outputs.

AssemblyResolutionException when publicizing internals on .Net Framework 4.6

1. Create a new .Net Framework 4.6 class library in Visual Studio.

2. Install the IgnoresAccessChecksToGenerator NuGet package (select the PackageReference package manager format)

3. Install the Microsoft.CodeAnalysis.Common package.

4. Add the following to the csproj in an external editor:

   <PropertyGroup>
     <InternalsAssemblyNames>Microsoft.CodeAnalysis</InternalsAssemblyNames>
   </PropertyGroup>

5. Reload the Project as prompted by VS.

6. Build solution.

This produces the error:

Error		The "PublicizeInternals" task failed unexpectedly.
Mono.Cecil.AssemblyResolutionException: Failed to resolve assembly: 'System.Runtime, Version=4.0.20.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
   at IgnoresAccessChecksToGenerator.Tasks.PublicizeInternals.AssemblyResolver.Resolve(AssemblyNameReference name, ReaderParameters parameters)
   at IgnoresAccessChecksToGenerator.Tasks.PublicizeInternals.AssemblyResolver.Resolve(AssemblyNameReference name)
   at Mono.Cecil.MetadataResolver.Resolve(TypeReference type)
   at Mono.Cecil.TypeReference.Resolve()
   at Mono.Cecil.Mixin.CheckedResolve(TypeReference self)
   at Mono.Cecil.MetadataBuilder.GetConstantType(TypeReference constant_type, Object constant)
   at Mono.Cecil.MetadataBuilder.AddConstant(IConstantProvider owner, TypeReference type)
   at Mono.Cecil.MetadataBuilder.AddField(FieldDefinition field)
   at Mono.Cecil.MetadataBuilder.AddFields(TypeDefinition type)
   at Mono.Cecil.MetadataBuilder.AddType(TypeDefinition type)
   at Mono.Cecil.MetadataBuilder.AddTypes()
   at Mono.Cecil.MetadataBuilder.BuildTypes()
   at Mono.Cecil.MetadataBuilder.BuildModule()
   at Mono.Cecil.MetadataBuilder.BuildMetadata()
   at Mono.Cecil.ModuleWriter.<>c.<BuildMetadata>b__2_0(MetadataBuilder builder, MetadataReader _)
   at Mono.Cecil.ModuleDefinition.Read[TItem,TRet](TItem item, Func`3 read)
   at Mono.Cecil.ModuleWriter.BuildMetadata(ModuleDefinition module, MetadataBuilder metadata)
   at Mono.Cecil.ModuleWriter.Write(ModuleDefinition module, Disposable`1 stream, WriterParameters parameters)
   at Mono.Cecil.ModuleWriter.WriteModule(ModuleDefinition module, Disposable`1 stream, WriterParameters parameters)
   at Mono.Cecil.ModuleDefinition.Write(String fileName, WriterParameters parameters)
   at IgnoresAccessChecksToGenerator.Tasks.PublicizeInternals.CreatePublicAssembly(String source, String target)
   at IgnoresAccessChecksToGenerator.Tasks.PublicizeInternals.Execute()
   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
   at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()

If I change the target framework to .Net Framework 4.7.2 and build again, the build succeeds.