Build Acceleration copies assemblies from wrong target framework in multi target setup #8908
Comments
|
Thanks for the detailed ticket
Yes this is supposed to work. I'll dig into your scenario and report back. It might not be until next week. |
I don't see any examples of copies from |
Nope. Sorry. It's written a bit confusing. I should have changed net462 to net7.0 At work we have net462 and net6.0-windows setup. Initially, I tried to recreate this in GitExtensions, but some dependencies didn't build for net462. Then I briefly tried .net6.0 and net7.0 and saw that the same happens there. You'll only see 6.0 and 7.0 as those are the |
|
I'd like to create a minimal repro for this, ideally with two projects, A and B, where A references B and B is multi-targeted. What would the targets of these projects need to be to recreate your scenario? |
|
For example, if A targets |
|
Hi Drew! Thanks for taking the time looking into this. I've only now noticed that my repro repo isn't even correct because those different platform assemblies that get copied are the only ones which are build as the corresponding projects have their own, stricter target platforms. They are essentially the only ones available. I am really not interested in wasting your time. Its ok for me, if we close this issue until, if, I'll come up with a usable repo. I think it's way more likely that the issue is on our side. I've quickly tested it with the example case you provided and everything works as expected. Then however, I've tried to re-create our build system, and I think the options we have set are similar to this:
<LangVersion>latest</LangVersion>
<TargetFrameworks>net462;net6.0-windows</TargetFrameworks>
<!-- Produce reference assemblies during compile for faster builds: https://learn.microsoft.com/en-us/dotnet/standard/assembly/reference-assemblies -->
<ProduceReferenceAssembly>true</ProduceReferenceAssembly>
<!-- Opt in to build acceleration in VS (from 17.5 onwards): https://github.com/dotnet/project-system/blob/main/docs/build-acceleration.md -->
<AccelerateBuildsInVisualStudio>true</AccelerateBuildsInVisualStudio>
<BaseOutputPath>..\Bin\</BaseOutputPath>
<AppendRuntimeIdentifierToOutputPath>true</AppendRuntimeIdentifierToOutputPath>
<OutputPath>$(BaseOutputPath)</OutputPath>
<UseCommonOutputDirectory>true</UseCommonOutputDirectory>So we have for all projects net462;net6.0-windows as targetplatforms, and a common output directory. Here is a new minimal project based on this with 4 test projects. I'm not even sure if that makes sense with build acceleration, now that I looked deeper into this. Now when I build it, and change something in ClassLibary2, TestMethod2, TestMethod2 (e.g. B), I see this output: Something is copied from net462 to net6.0-windows (log). I think TestFramework.Extensions.dll isn't needed in this case for .net6.0. So the copy isn't bad. In our case however, our production assemblies get copied over. And I am guessing right now it might be because they are many times rebuild during the build because the fail the FUTD check all the time. |
|
HI Johannes, I cloned your repo down and did the following:
The output window shows me something different to you. I see Then scrolling down to Here the source and destination paths are actually the same, due to the use of the common output directory. Note that I'm using verbose output. I think you're using info. Interestingly, I see no mention at all of Full build outputBuild started... Firstly, I wonder if we are using the same repro steps. If you follow the steps I gave above, do you see the same output as me? Do I need different steps to reproduce your output? If the same steps produce different results on our two machines, we will need to gather some additional logs. Another thing you could try is installing the 17.6 preview to see if that makes a difference. I'm using an internal build of 17.6p2. That said, I'm not aware of any change between 17.5 GA and 17.6 that could cause the difference between what we're seeing. |
drewnoakes
added
the
Feature-Build-Acceleration
drewnoakes
added
Triage-Investigate
|
Hi Drew, I've figured out what our problem is in our solution. We have something like this: graph TD;
A1["ConsoleApp1<br>(net462;net6.0-windows)"]-->L1["ClassLibrary1<br>(net462)"];
A1-->L2["ClassLibrary2<br>(net462;net6.0-windows)"];
L1-->L2;
L2-->L3["ClassLibrary3<br>(net462;net6.0-windows)"];
After changing the implementation in ClassLibrary2 and performing an incremental build, in the ConsoleApp1
Build Acceleration OutputMSBuild OutputThe output from build acceleration is just "different" compared to MSBuild. But I think that the actual problem is of course our code as its somewhat ill specified as we have two ways we reference ClassLibrary2 via different target platforms. I've updated my previous repo accordingly so that you can test it. I've also added msbuild and build acceleration logs in the logs folder of the repository. Overall, I don't think this is an issue anymore. I just wanted to give you a short retrospective feedback of the issue. I'm sorry for opening this prematurely. Thanks for your help. Best, |
|
Revisiting this, I think these are the points raised in the above:
So I believe this issue can be closed in favour of those two issues. Thanks very much @johanneszab for trying out the feature and filing this feedback. It's very much appreciated. |
Visual Studio Version
Version 17.5.1
Summary
In a multi-target frameworks setup, Build Acceleration copies assemblies from one target framework (e.g. net7.0) to the output of a different target framework (net6.0). Is Build Acceleration suitable for multi-target frameworks setups? I haven't seen anything regarding this in the docs.
Steps to Reproduce
net6.0-windowstonet7.0-windows;net6.0-windows.GitExtUtilsto trigger Build Acceleration.net462tonet6.0-windows).Expected Behavior
Assemblies from one target platform should only be copied to its appropriate output and not being mixed.
Actual Behavior
Assemblies from one target platform are copied to the other output directory (e.g. from
net462tonet6.0-windows).User Impact
We are still in the migration phase of a huge (500+ projects, multi million LoCs) .net framework solution and are currently targeting .net462 and .net6.0-windows. We cannot use Build Acceleration as it breaks builds by copying .net462 assemblies to the .net6.0-windows output folder.
The text was updated successfully, but these errors were encountered: