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

Allow custom OutputFile #10

Open
Pretasoc opened this issue Jul 24, 2019 · 3 comments
Open

Allow custom OutputFile #10

Pretasoc opened this issue Jul 24, 2019 · 3 comments

Comments

@Pretasoc
Copy link

In multi target solutions, the fixed output path of the [AssemblyName].ExternalAnnotations.xml leads to problems. If such a solution is build in parallel multiple programs, will attempt to write possible different content to the same file.

Is there a possibility to specify the output folder for the external annotations from the .csproj file?

@tom-englert
Copy link
Owner

Actually not - I never ran into problems with this.
Do you have an idea how this could work? Where can we place it so msbuild will copy it to the proper bin folder and optionally pack it with the .nuget package?

@gtbuchanan
Copy link

I have run into this same issue with multitargeting and parallel builds. My workaround has just been to limit MSBuild to 1 CPU. The actual error message is:

The process cannot access the file '[AssemblyName].ExternalAnnotations.xml' because it is being used by another process

Would it be possible to include the short target framework moniker into the initial file name when multitargeting and have it stripped when it's copied to the appropriate output directory? Example:

.NET Standard 2.0: [AssemblyName].ExternalAnnotations.netstandard2.0.xml
.NET Core 3.1: [AssemblyName].ExternalAnnotations.netcoreapp3.1.xml
.NET 4.8: [AssemblyName].ExternalAnnotations.net48.xml

This is how I handle multiple frameworks for PublicApiGenerator. Granted, I don't have to copy to output directories in this case.

@tom-englert
Copy link
Owner

@gtbuchanan copy to output directories and nuget packaging is handled by msbuild, so I have no control over this.
One solution could be to catch the IOException and retry sometimes.

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

No branches or pull requests

3 participants