-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
[Bug]: Project object can no longer be created if the change wave 17.10 is in use. #9869
Comments
@MarkKharitonov you are loading MSBuild from VS, which is built to target .NET Framework - into a .NET 8 app. I'm afraid this is unsupported and the fact that it worked before 17.9 would be considered a lucky accident. @rainersigwald have we ever made such guarantees before? Do you think it's generally a reasonable expectation for the NetFx MSBuild to be usable in a .NET process, at least to the point that it can evaluate a project? (Incidentally, the change that broke this is being reverted for other reasons and the next servicing release of 17.9 should work for you again. We have another change lined up for 17.10, though, which will have a similar effect.) |
@ladipro - would you be able to recommend the proper way to do it? My goal is to have a tool written in the modern .NET stack (like .NET 8) that analyzes projects targeting .NET 4. Some of these projects are not even SDK style projects. The code I have attached is what I have used so far with success. But if it is wrong, I will gladly change it with your help (hopefully). |
No, and actually we should probably put an explicit break in MSBuildLocator for this (cc @YuliiaKovalova). @MarkKharitonov Unfortunately if you want to analyze non-SDK projects targeting .NET 4 (or 3.5 or whatever) your tool must run on .NET Framework today. |
That is indeed very unfortunate, since there is a ton of legacy code out there to be analyzed. This requirement for a tool to be written in .NET Framework in order to analyze code written in .NET Framework (using msbuild API) - was it documented anywhere? Maybe I have missed that part. For me (granted, not the mainstream case) this is a breaking change. |
That's how it's been since the first port of MSBuild in .NET Core 1.0; MSBuild on .NET Framework is the compatible can-load-anything solution. I'm genuinely surprised you ever got it to work even partially. |
Some analysis tools will use a modern .NET process that will spawn a child process to use MSBuild to extract information about non-SDK projects and pass it back via IPC. |
I cannot explain it, of course, since I do not understand the root of the problem. But it did work and still does if I disable the new feature through that environment variable. It is very problematic to target .NET 4, because it prevents me from using the latest versions of all kinds of packages I depend on. And to implement IPC and spawn child processes is, of course, possible, but it makes the tool so much more complicated... |
I think the best way to describe the problem is that .NET (Core) API is not a superset of .NET Framework API and it is certainly not bug-for-bug compatible. So while the VS MSBuild and the .NET SDK MSBuild share most of the code, there are places where the code is platform-specific, such as to take advantage of a feature present in one but not the other. I believe in this case we're looking at differences in assembly binding behavior. It probably would be technically possible to keep the scenario of cross-loading working, but it would mean additional code complexity and a larger test matrix, so more dev burden for something that's not architecturally sound to begin with. |
Closing as won't fix. @MarkKharitonov you should be good with |
@ladipro - may I get a moment of your time once more? I changed the csproj file by replacing
With
But it still does not work. This time the error is different and it is the same whether the environment variable is set or unset:
Would you be able to indicate what I am doing wrong? Thank you so much. |
I also asked the question here - https://stackoverflow.com/questions/78253252/what-is-the-correct-method-to-analyze-net-4-7-2-projects-using-msbuild-api |
@MarkKharitonov I don't reproduce your failure--your code works fine for me. What versions of EVERYTHING are set up in the repro environment? |
@rainersigwald - I have pushed a small test code to GitHub - https://github.com/MarkKharitonov/test_load_msbuild_project. I will copy here the Introduction and the final Summary from the README: IntroductionThis README shows the result of running the tool in 3 different environments x 2 different target frameworks x 3 kinds of projects to be parsed: 3 different run environments:
2 different target frameworks (for which the tool is compiled):
3 kinds of projects to be parsed:
By default sample_net472_legacy.proj is parsed. To parse another project pass its path on the command line. The runs where done with Visual Studio 2022 version 17.9.5 and .NET 8 CLI:
... SummaryThe code must target .NET 8 in order to be able to parse both SDK and non SDK style projects targeting .NET or .NET Framework.
All the errors are the same one:
As far as I understand, my tool must target .NET 4.7.2 , but I just cannot make it work. Your help is greatly appreciated. |
@MarkKharitonov, I cannot reproduce this either. It looks like on your system the tool is picking up |
@ladipro - sure I can do it. But I have multiple run environments comprised of different target frameworks, ways to run (IDE, dev console, bare) and projects to parse (legacy/sdk, .NET Framework/.NET). Which one would you like me to run? |
@MarkKharitonov, oh, any environment where you're getting the |
Ouch. Stupid me. I must have placed it there while trying to make it work with the previous version of Visual Studio. I removed the file and now all the matrix cases work beautifully. Since it works I will continue to target .NET 8 in my tool even if it parses projects targeting .NET Framework 4.7.2. It would be fantastic if this ability is not broken in the future, even though you guys are saying it will be. |
@ladipro I hate to bother you again, but with the release of 17.10 the code that worked before no longer works. The test project is still available at https://github.com/MarkKharitonov/test_load_msbuild_project.git. I pushed a change where I hard code the location of the msbuild.exe to the locally built one (from this repo). When I build msbuild at v17.9.8 and then run my app here is what I get:
All is great. However, when I build msbuild at v17.10.4 and rerun the same commands, I get this result:
I am pretty sure it is related to #9446. Please, advise. |
@MarkKharitonov so this is still loading the net472 build of MSBuild into a .NET 8 process, is that correct? As discussed before, it's unfortunately not a supported scenario. Though in this case, there may be a relatively simple workaround, let me try something. |
Issue Description
Consider the following code:
And assume
SLN_DIR_PATH + CSPROJ_REL_PATH
point at an existing csproj file with a solution file insideSLN_DIR_PATH
.When I run this code - it succeeds. However, if I comment the
MSBUILDDISABLEFEATURESFROMVERSION
line, then it fails with the following exception:Steps to Reproduce
scratch.zip
msbuild.zip
Since the binary log is small and without any secrets, I just renamed
msbuild.binlog
tomsbuild.,zip
and uploaded here.To show the issue pass the 3rd parameter
exp
.Good run
Bad run
Expected Behavior
The code succeeds without disabling the latest change wave.
Actual Behavior
The code fails.
Analysis
No response
Versions & Configurations
See the attached msbuild binary log, but here it is:
The text was updated successfully, but these errors were encountered: