Refactor ref src generators & pass ref assemblies#547
Refactor ref src generators & pass ref assemblies#547MichaelSimons merged 6 commits intodotnet:mainfrom
Conversation
ce0e7d5 to
ddaf0e1
Compare
|
Hello @ViktorHofer , I tried to run the generator from a PR branch and got an error: "The "MSBuildInParallel" parameter is not supported by the "MSBuild" task loaded from assembly". And I took the latest commit.
|
736f8b4 to
d1b0db5
Compare
> ./generate.sh --pkg System.Threading.Tasks,4.3.0
Determining projects to restore...
All projects are up-to-date for restore.
/repos/source-build-reference-packages/src/referencePackageSourceGenerator/ReferencePackageSourceGenerator.csproj(9,5): error MSB4184: The expression "[MSBuild]::NormalizeDirectory('', '')" cannot be evaluated. Parameter "path" cannot have zero length. |
Hm, I didn't notice that as I am using |
|
Taking a look |
|
One more thing @MichaelSimons , The version from main generates packages and direct dependencies and the version from the PR - direct and transitive dependencies. What 'd be a desired behavior? The same as original version of SBRP? From the main:microsoft.codeanalysis.common From the PR branch:microsoft.codeanalysis.common |
|
Btw. Viktor introduced a new parameter |
Transitive. I am not sure why it didn't behave this way in the first place. It provides the best UX and doesn't require the user to figure out the graph and run generate multiple times. |
4e21811 to
40f7b37
Compare
|
@MichaelSimons the error above is now fixed. The generate.sh script always appended msbuild properties even if they weren't set which led to default properties and in this case paths not being honored. I changed the script to only append switches when they are provided (which is the desired behavior anyway). |
2296a97 to
2f9e131
Compare
|
With the current branch, the following dependency closure gets transformed to reference package source when invoking @andriipatsula's previous list was longer because we didn't filter out targeting packs before. That's now fixed. The remaining issue is that text only packages are considered during the reference package source traversal: We could either ignore them (existing behavior) or pass them to the text only package generator. Alternatively, we could also merge both generators so that it can handle both types of packages. Text only packages could be identified by looking at the number of compile items. |
2f9e131 to
b1429b1
Compare
|
The SBRP generator LGTM. I run smoke tests and the tool behaves as expected. Thank you @ViktorHofer . @MichaelSimons, could you please check the question related to text-only packages above:
|
|
My main requirement is that text-only packages remain in a separate location of the repo. It is important that their is a distinction made between them and ref packages because the rules for consuming them are very different. There is a bar for adding new ones (e.g. it would be preferred that we truly source-build them). Because of that I do think it is preferable that you must take an explicit action to generate them. I see value in having a single set of tools that would support either. My only request would be to do any additional refactoring separately as we would like to realize the immediate benefit of this PR. What was the reason that made us not include allowed content in reference source packages? - I don't have the history here. I can speculate one reason was to avoid bloat from non-required content for the required usage scenarios. We are trying to reduce the size of this repo so bringing in a bunch of things like icons would work against this for no real value. Regarding text-only packages referenced by reference packages, I think we should continue to ignore them as is the current behavior. We can reconsider this if it becomes a UX concern. |
b1429b1 to
8a2d49f
Compare
- Refactor textonly & reference source generators - Pass the right reference assemblies to GenAPI invocation - Make GenAPI generate assembly attributes and typeforwards - Use PackageDownload instead of extra restore project - Use the default package cache instead of defining a separate one - Make the ref generator work with multi-assembly packages - Make the generators work cross-plat - Add "--exclude-package-dependencies" switch to ignore dependencies
bc52865 to
f5264e1
Compare
|
The PR should now be ready to be merged. I tested it with Microsoft.CodeAnalysis.Common + its dependencies and with System.Drawing.Common + dependency.
|
|
@MichaelSimons would you mind taking another look and if everything's good, merge the PR in? |
src/referencePackageSourceGenerator/ReferencePackageSourceTask/GetPackageItems.cs
Outdated
Show resolved
Hide resolved
| [Required] | ||
| public string ProjectTemplate { get; set; } | ||
|
|
||
| public override bool Execute() |
There was a problem hiding this comment.
IMO the readability of this method could be improved by breaking it apart a bit.
There was a problem hiding this comment.
I left it as is as this was already a single method in main:
While I agree with the principle of factoring responsibilities into different methods, I would recommend to follow-up on that in a separate change. Also, this PR already adds ton of code comments and significantly reduces the code size because of simplification.
There was a problem hiding this comment.
That's fair, with all the refactoring I lost sight of original code. I appreciate the effort you invested to improve the codebase - thanks.
|
How should I interpret the following errors when running |
|
Another scenario: In this scenario, only the microsoft.codeanalysis.csharp,4.0.1 package way generated. It's dependency graph was not. |
|
@MichaelSimons thanks for the feedback so far 👍
The ´AssemblyLoadWarning` warnings are reasonable and should stay. In the case of .NET Framework, reference assemblies are missing (intentionally AFAIK as those never got exposed in the reference assemblies pack). Those warnings were propagated to errors which I just fixed. The package downgrade is intentional, as we are referencing a specific version of a package which might be a lower version than what other dependencies (targeting pack) might bring in. I just added a NoWarn for it.
Fixed. That package had fixed versions for its dependencies and the tooling / NuGet APIs handled that incorrectly. |
Fixes dotnet/source-build#3252
Fixes dotnet/source-build#3237
cc @andriipatsula @MichaelSimons