Fix InternalsVisibleTo for versioned assemblies #4581
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit fixes the inclusion of InternalsVisibleToAttributes for versioned assemblies. Directory.Build.Targets defines an AssemblyInfos target that writes InternalsVisibleTo elements for friend assemblies and versioned friend assemblies, based on the InternalsVisibleTo elements in the target csproj and the version being built. This worked fine when built from Rider IDE (and likely Visual Studio too) due to the way in which MsBuild is invoked from IDE, but did not work as intended when built from the commandline with the build script, which calls dotnet build; The Nest InternalsVisibleTo was correctly written, but none of the InternalsVisibleTo for generated Elasticsearch.Net assemblies were. Looking at the binarylog for MsBuild with the Structured Log Viewer indicated that the task was working as expected from the command line and \obj\$(Configuration\AssemblyInfo.cs generated file was written correctly, but inspection of the file revealed that the InternalsVisibleTo attributes were in fact not generated correctly. In researching friend assemblies, https://docs.microsoft.com/en-us/dotnet/standard/assembly/friend notes the following > When you compile an assembly like AssemblyB that will access internal types or internal members of another assembly like Assembly A, you must explicitly specify the name of the output file (.exe or .dll) by using the -out compiler option. This is required because the compiler has not yet generated the name for the assembly it is building at the time it is binding to external references. The build script does not pass an output path, relying on the convention of output going to /bin/$(Configuration)/$(TargetFramework)/. When the IDE builds projects, it explicitly passes an output path. In summary, the fix to allow InternalsVisibleTo to work as expected from the commandline is to explicitly pass an output path. This is done for all projects by adding <OutDir>bin/$(Configuration)/$(TargetFramework)/</OutDir> to Directory.Build.Targets. Fixes #4538
codebrain
approved these changes
Apr 14, 2020
Contributor
Author
|
does not need to be backported to 6.x and 5.x as they both specify |
github-actions bot
pushed a commit
that referenced
this pull request
Apr 15, 2020
This commit fixes the inclusion of InternalsVisibleToAttributes for versioned assemblies. Directory.Build.Targets defines an AssemblyInfos target that writes InternalsVisibleTo elements for friend assemblies and versioned friend assemblies, based on the InternalsVisibleTo elements in the target csproj and the version being built. This worked fine when built from Rider IDE (and likely Visual Studio too) due to the way in which MsBuild is invoked from IDE, but did not work as intended when built from the commandline with the build script, which calls dotnet build; The Nest InternalsVisibleTo was correctly written, but none of the InternalsVisibleTo for generated Elasticsearch.Net assemblies were. Looking at the binarylog for MsBuild with the Structured Log Viewer indicated that the task was working as expected from the command line and \obj\$(Configuration\AssemblyInfo.cs generated file was written correctly, but inspection of the file revealed that the InternalsVisibleTo attributes were in fact not generated correctly. In researching friend assemblies, https://docs.microsoft.com/en-us/dotnet/standard/assembly/friend notes the following > When you compile an assembly like AssemblyB that will access internal types or internal members of another assembly like Assembly A, you must explicitly specify the name of the output file (.exe or .dll) by using the -out compiler option. This is required because the compiler has not yet generated the name for the assembly it is building at the time it is binding to external references. The build script does not pass an output path, relying on the convention of output going to /bin/$(Configuration)/$(TargetFramework)/. When the IDE builds projects, it explicitly passes an output path. In summary, the fix to allow InternalsVisibleTo to work as expected from the commandline is to explicitly pass an output path. This is done for all projects by adding <OutDir>bin/$(Configuration)/$(TargetFramework)/</OutDir> to Directory.Build.Targets. Fixes #4538
This was referenced Apr 15, 2020
github-actions bot
pushed a commit
that referenced
this pull request
Apr 15, 2020
This commit fixes the inclusion of InternalsVisibleToAttributes for versioned assemblies. Directory.Build.Targets defines an AssemblyInfos target that writes InternalsVisibleTo elements for friend assemblies and versioned friend assemblies, based on the InternalsVisibleTo elements in the target csproj and the version being built. This worked fine when built from Rider IDE (and likely Visual Studio too) due to the way in which MsBuild is invoked from IDE, but did not work as intended when built from the commandline with the build script, which calls dotnet build; The Nest InternalsVisibleTo was correctly written, but none of the InternalsVisibleTo for generated Elasticsearch.Net assemblies were. Looking at the binarylog for MsBuild with the Structured Log Viewer indicated that the task was working as expected from the command line and \obj\$(Configuration\AssemblyInfo.cs generated file was written correctly, but inspection of the file revealed that the InternalsVisibleTo attributes were in fact not generated correctly. In researching friend assemblies, https://docs.microsoft.com/en-us/dotnet/standard/assembly/friend notes the following > When you compile an assembly like AssemblyB that will access internal types or internal members of another assembly like Assembly A, you must explicitly specify the name of the output file (.exe or .dll) by using the -out compiler option. This is required because the compiler has not yet generated the name for the assembly it is building at the time it is binding to external references. The build script does not pass an output path, relying on the convention of output going to /bin/$(Configuration)/$(TargetFramework)/. When the IDE builds projects, it explicitly passes an output path. In summary, the fix to allow InternalsVisibleTo to work as expected from the commandline is to explicitly pass an output path. This is done for all projects by adding <OutDir>bin/$(Configuration)/$(TargetFramework)/</OutDir> to Directory.Build.Targets. Fixes #4538
github-actions bot
pushed a commit
that referenced
this pull request
Apr 15, 2020
This commit fixes the inclusion of InternalsVisibleToAttributes for versioned assemblies. Directory.Build.Targets defines an AssemblyInfos target that writes InternalsVisibleTo elements for friend assemblies and versioned friend assemblies, based on the InternalsVisibleTo elements in the target csproj and the version being built. This worked fine when built from Rider IDE (and likely Visual Studio too) due to the way in which MsBuild is invoked from IDE, but did not work as intended when built from the commandline with the build script, which calls dotnet build; The Nest InternalsVisibleTo was correctly written, but none of the InternalsVisibleTo for generated Elasticsearch.Net assemblies were. Looking at the binarylog for MsBuild with the Structured Log Viewer indicated that the task was working as expected from the command line and \obj\$(Configuration\AssemblyInfo.cs generated file was written correctly, but inspection of the file revealed that the InternalsVisibleTo attributes were in fact not generated correctly. In researching friend assemblies, https://docs.microsoft.com/en-us/dotnet/standard/assembly/friend notes the following > When you compile an assembly like AssemblyB that will access internal types or internal members of another assembly like Assembly A, you must explicitly specify the name of the output file (.exe or .dll) by using the -out compiler option. This is required because the compiler has not yet generated the name for the assembly it is building at the time it is binding to external references. The build script does not pass an output path, relying on the convention of output going to /bin/$(Configuration)/$(TargetFramework)/. When the IDE builds projects, it explicitly passes an output path. In summary, the fix to allow InternalsVisibleTo to work as expected from the commandline is to explicitly pass an output path. This is done for all projects by adding <OutDir>bin/$(Configuration)/$(TargetFramework)/</OutDir> to Directory.Build.Targets. Fixes #4538
russcam
added a commit
that referenced
this pull request
Apr 15, 2020
This commit fixes the inclusion of InternalsVisibleToAttributes for versioned assemblies. Directory.Build.Targets defines an AssemblyInfos target that writes InternalsVisibleTo elements for friend assemblies and versioned friend assemblies, based on the InternalsVisibleTo elements in the target csproj and the version being built. This worked fine when built from Rider IDE (and likely Visual Studio too) due to the way in which MsBuild is invoked from IDE, but did not work as intended when built from the commandline with the build script, which calls dotnet build; The Nest InternalsVisibleTo was correctly written, but none of the InternalsVisibleTo for generated Elasticsearch.Net assemblies were. Looking at the binarylog for MsBuild with the Structured Log Viewer indicated that the task was working as expected from the command line and \obj\$(Configuration\AssemblyInfo.cs generated file was written correctly, but inspection of the file revealed that the InternalsVisibleTo attributes were in fact not generated correctly. In researching friend assemblies, https://docs.microsoft.com/en-us/dotnet/standard/assembly/friend notes the following > When you compile an assembly like AssemblyB that will access internal types or internal members of another assembly like Assembly A, you must explicitly specify the name of the output file (.exe or .dll) by using the -out compiler option. This is required because the compiler has not yet generated the name for the assembly it is building at the time it is binding to external references. The build script does not pass an output path, relying on the convention of output going to /bin/$(Configuration)/$(TargetFramework)/. When the IDE builds projects, it explicitly passes an output path. In summary, the fix to allow InternalsVisibleTo to work as expected from the commandline is to explicitly pass an output path. This is done for all projects by adding <OutDir>bin/$(Configuration)/$(TargetFramework)/</OutDir> to Directory.Build.Targets. Fixes #4538 Co-authored-by: Russ Cam <[email protected]>
russcam
added a commit
that referenced
this pull request
Apr 15, 2020
This commit fixes the inclusion of InternalsVisibleToAttributes for versioned assemblies. Directory.Build.Targets defines an AssemblyInfos target that writes InternalsVisibleTo elements for friend assemblies and versioned friend assemblies, based on the InternalsVisibleTo elements in the target csproj and the version being built. This worked fine when built from Rider IDE (and likely Visual Studio too) due to the way in which MsBuild is invoked from IDE, but did not work as intended when built from the commandline with the build script, which calls dotnet build; The Nest InternalsVisibleTo was correctly written, but none of the InternalsVisibleTo for generated Elasticsearch.Net assemblies were. Looking at the binarylog for MsBuild with the Structured Log Viewer indicated that the task was working as expected from the command line and \obj\$(Configuration\AssemblyInfo.cs generated file was written correctly, but inspection of the file revealed that the InternalsVisibleTo attributes were in fact not generated correctly. In researching friend assemblies, https://docs.microsoft.com/en-us/dotnet/standard/assembly/friend notes the following > When you compile an assembly like AssemblyB that will access internal types or internal members of another assembly like Assembly A, you must explicitly specify the name of the output file (.exe or .dll) by using the -out compiler option. This is required because the compiler has not yet generated the name for the assembly it is building at the time it is binding to external references. The build script does not pass an output path, relying on the convention of output going to /bin/$(Configuration)/$(TargetFramework)/. When the IDE builds projects, it explicitly passes an output path. In summary, the fix to allow InternalsVisibleTo to work as expected from the commandline is to explicitly pass an output path. This is done for all projects by adding <OutDir>bin/$(Configuration)/$(TargetFramework)/</OutDir> to Directory.Build.Targets. Fixes #4538 Co-authored-by: Russ Cam <[email protected]>
russcam
added a commit
that referenced
this pull request
Apr 15, 2020
This commit fixes the inclusion of InternalsVisibleToAttributes for versioned assemblies. Directory.Build.Targets defines an AssemblyInfos target that writes InternalsVisibleTo elements for friend assemblies and versioned friend assemblies, based on the InternalsVisibleTo elements in the target csproj and the version being built. This worked fine when built from Rider IDE (and likely Visual Studio too) due to the way in which MsBuild is invoked from IDE, but did not work as intended when built from the commandline with the build script, which calls dotnet build; The Nest InternalsVisibleTo was correctly written, but none of the InternalsVisibleTo for generated Elasticsearch.Net assemblies were. Looking at the binarylog for MsBuild with the Structured Log Viewer indicated that the task was working as expected from the command line and \obj\$(Configuration\AssemblyInfo.cs generated file was written correctly, but inspection of the file revealed that the InternalsVisibleTo attributes were in fact not generated correctly. In researching friend assemblies, https://docs.microsoft.com/en-us/dotnet/standard/assembly/friend notes the following > When you compile an assembly like AssemblyB that will access internal types or internal members of another assembly like Assembly A, you must explicitly specify the name of the output file (.exe or .dll) by using the -out compiler option. This is required because the compiler has not yet generated the name for the assembly it is building at the time it is binding to external references. The build script does not pass an output path, relying on the convention of output going to /bin/$(Configuration)/$(TargetFramework)/. When the IDE builds projects, it explicitly passes an output path. In summary, the fix to allow InternalsVisibleTo to work as expected from the commandline is to explicitly pass an output path. This is done for all projects by adding <OutDir>bin/$(Configuration)/$(TargetFramework)/</OutDir> to Directory.Build.Targets. Fixes #4538 Co-authored-by: Russ Cam <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit fixes the inclusion of InternalsVisibleToAttributes for
versioned assemblies.
Directory.Build.Targets defines an AssemblyInfos target that
writes InternalsVisibleTo elements for friend assemblies and
versioned friend assemblies, based on the InternalsVisibleTo
elements in the target csproj and the version being built. This worked
fine when built from Rider IDE (and likely Visual Studio too) due to
the way in which MsBuild is invoked from IDE, but did not work as intended
when built from the commandline with the build script, which calls
dotnet build; The Nest InternalsVisibleTo was correctly written, but
none of the InternalsVisibleTo for generated Elasticsearch.Net assemblies
were. Looking at the binarylog for MsBuild with the Structured Log Viewer
indicated that the task was working as expected from the command line and
\obj\$(Configuration\AssemblyInfo.csgenerated file was written correctly,but inspection of the file revealed that the InternalsVisibleTo attributes
were in fact not generated correctly.
In researching friend assemblies, https://docs.microsoft.com/en-us/dotnet/standard/assembly/friend
notes the following
The build script does not pass an output path, relying on the convention of
output going to
/bin/$(Configuration)/$(TargetFramework)/. When the IDEbuilds projects, it explicitly passes an output path. In summary, the fix to
allow InternalsVisibleTo to work as expected from the commandline is to explicitly
pass an output path. This is done for all projects by adding
to Directory.Build.Targets.
Fixes #4538