The Microsoft Build Engine (MSBuild) is the build platform for .NET and Visual Studio.
Q: do things like
Directory.Build.props get cached at all? reason I ask, I shifted gears in my assembly versioning strategy, and I am seeing evidence of the old strategy on the frist next build. If I re-run the build, seems to be fine, like the next properties got cached.
or perhaps this way, so-called
.csproj gets rolled up, including any build properties, imported projects, etc, and cached.
I asked this before I think... I need a list of build targets, especially vis-a-vis the NuGet packaging step, in particular with the objective of timing a bump assembly version such that the requisite versions are available at the time when Nuget does its packaging.
at the moment, I am noticing that the bump is happening, but that nuget seems to be packaging using the version prior to the bump.
at the moment, I am noticing that the bump is happening, but that nuget seems to be packaging using the version prior to the bump.
Hey guys, I have a dotnet tool that uses MSBuild programmatically. It leverages MSBuildLocator to find the appropriate installation. But I was wondering, what are the recommendations/limitations for targeting a specific version of MSBuild. If I target 16.X can my tool fail on any version lower than that? Anyway to enforce constraints?
Sorry if this isn't exactly the right place, feel free to point me elsewhere.
Any time you compile against a newer version of an API and run against an older version, there's the chance that you'll call into something that doesn't exist and you get MissingMethodException. Or maybe your app even fails to load MSBuild. I would guess that MSBuildLocator spies on the calling assembly (yours) to see which version of MSBuild you reference and uses that as a filter, but I have no real idea. You'd have to try it perhaps.
Would someone mind clarifying, my bump assembly versions did the following under single target and multi target conditions. AFAIK, this used to work fine under VS2017 hosted builds. But under VS2019 the result appears to be once again a cached version prior to bump that informs nuget packaging. This is, of course, a problem. The nuget should be using what it finds as current, notwithstanding build
Thanks, cheers...
Target timing.<Target Name="BumpAssemblyVersionsBeforeBuild" BeforeTargets="BeforeBuild" Condition="'$(TargetFrameworks)' == ''"><CallTarget Targets="GeneralBumpAssemblyVersions" /></Target><Target Name="BumpAssemblyVersionsBeforeDispatchToInnerBuilds" BeforeTargets="DispatchToInnerBuilds" Condition="'$(TargetFrameworks)' != ''"><CallTarget Targets="GeneralBumpAssemblyVersions" /></Target>Thanks, cheers...
So in other words, the version in the
.csproj or AssemblyInfo.cs as the case may be indicates x+1 whereas the package output indicates myproject.x.nupkg.
oh, ah, so if we did
BeforeTargets="BeforeCompile;CoreCompile" ... That should work then, in either single or multi target cases.
:thumbsup:
I noticed that a lot of APIs within Roslyn/MSBuild support reading Solutions, but refrain from supporting altering them. Besides just never getting to it, is there a reason for this? I also notice that a lot of the .NET Ecosystem tooling leverages internal solutions. For instance, the
dotnet sln tool is using a port of an internal solution representation from the Xamarin guys.
Example: I can load a solution in
MSBuildWorkspace and add a project to the solution. I get a new solution as a result and ask MSBuildWorkspace to TryApplyChanges. Now if I changed something like a document or a project, then the changes persist. But if I changed something about the solution file, the changes do not persist.
@kassemsandarusi I'm not quite following how you are making these "changes". If you're doing it outside the knowledge of the Roslyn APIs, then you perhaps are short-circuiting something. But, the
Roslyn is doing incremental compiles on documents all the time -- as you type in a document, as are countless other extensions, such as analyzers. Were any of those objects mutable, then it would be nearly impossible to get a self-consistent view of the world to analyze.
Solution, Project, and Document objects are all immutable. If you change a Document by modifying SyntaxNode's, for example, that produces a new Document object in a new Project within a new Solution. That change lives in memory until you call TryApplyChanges, at which point the workspace will have a new Solution instance assigned to its CurrentSolution.Roslyn is doing incremental compiles on documents all the time -- as you type in a document, as are countless other extensions, such as analyzers. Were any of those objects mutable, then it would be nearly impossible to get a self-consistent view of the world to analyze.
But it only parses, doesn't write?
For clarity, I'm looking at writing external tooling outside of Visual Studio. So I don't exactly have access to VisualStudioWorkspace afaik
I think it will also do real Project-level changes iirc @kfertitta . But it won't do solution level changes.
Which gets me to my original point lol
There's no central package for read AND write capabilities of a solution that I'm aware of.
Like.. I see a lot of purposely internal classes meant for parsing and writing to solution files, but no public API
Look, the dotnet CLI has solution read and write capabilities that it copied from Xamarin and it's internal! Why isn't the original Xamarin version just reusable?
@kassemsandarusi Sorry if there was a misunderstanding here, but when you say "solution-level changes", it's not clear what you mean. It certainly will add/remove projects, which is typically what is meant by solution-level changes. If you are talking about directly writing to the solution file and expecting Roslyn to detect or maintain that, then you are definitely running with scissors and probably on an unsupported path. For most users, solutions in Roslyn are supported well because they are a container of projects. If you're trying to use it for more than that, then you could get the impression they aren't supported well. Personally, I consider that lack of support a "feature". VSCode, for example, doesn't use solutions and, in many ways, life is better. The Configuration Manager in VS and how it interacts with the solution file has been a nightmare for years and never seems to get better. And, most users mental model of a solution is something that they could potentially delete altogether and recreate by starting from scratch and adding in the projects of interest. If you're relying on data in them, then this won't hold for your solutions, and that might surprise your users. Bottom line: projects are what matter and solutions are often just in your way.
@kfertitta Roslyn itself has no concept of Solutions or Project files. Those are MSBuild concepts so I get that I shouldn't expect it to write directly to those files. I do think the extension, MSBuildWorkspace should be able to. It already is able to with projects.
Also -- VSCode does support solutions. At least OmniSharp does which I believe is based off the the Roslyn Workspace API
You're right that Projects are really what matters as opposed to solutions. But for me, Solutions are valuable for providing a loadable 'view' for large codebases. For instance, I regularly work in a monolithic codebase with 200+ projects (including test projects). We use Solutions for a variety of views. For example, creating an 'all projects view' for when you need to make mass refactors. In general its a good tool for enabling an organization of developers to make better sense of the codebase they're working in.
So all that being said, I was generally surprised that a lot of the .NET ecosystem has written internal solution readers/writers and not exposed the capability in a redistributable fashion. It just made me wonder if there were reasons for that. I suspected that Solutions were not necessarily the tool of the future, because like you said newer tools like VSCode de-emphasize their use.
As I pointed out above, MSBuildWorkspace does have code that writes to files. Not sure why you say Roslyn doesn’t know about them. There’s TextDocumentChanged events and handling code. How is that anything other than a file? Anyway, my point is simply that I personally wouldn’t tool off of solutions, which seemed to be the crux of your question. It’s not that a logical organization of projects isn’t useful, it’s just how they’ve been implemented in VS that irks me. I mentioned the Configuration Manager. Another one is that I’m forced to include in a Solution all dependent projects even if I’m only interested in one project. I was just trying to offer tooling advice relative to solutions. We’ve built a lot of VS tooling over the years and have always avoided putting any data we rely upon in solution files as much as possible. Just my $0.02.
Sorry when I think of
MSBuildWorkspace I think of MSBuild's implementation of the Roslyn workspace. Roslyn itself has an object model for these things but doesn't necessarily have the code to do IO, and MSBuild is the 'manager' of the files (at least the build system ones). That view might be incorrect though.
@kfertitta an example of tooling I was looking at creating was dealing with moving projects or cleaning unnecessary projects from Solutions. Just some primitive quality of life tools for working in larger codebases. In those cases I need something that can work with Solutions.
2 replies
I gotta say, the docs say an awful lot about the inputs, properties, etc, but stop short of actually disclosing what the target names are. That would be the first thing I should think is identified. Or at least a reference to such a list.