by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 31 2019 22:54

    rainersigwald on vsix-depend-on-nuget

    VSIX dependency on NuGet.BuildT… Disambiguate branch name (compare)

  • Jan 31 2019 22:45
    livarcocc review_requested #4121
  • Jan 31 2019 22:45
    livarcocc review_requested #4121
  • Jan 31 2019 22:45
    livarcocc opened #4121
  • Jan 31 2019 22:42
    daryllabar commented #545
  • Jan 31 2019 21:40
    JL2210 edited #4116
  • Jan 31 2019 21:40
    JL2210 edited #4116
  • Jan 31 2019 21:39
    JL2210 commented #4116
  • Jan 31 2019 21:05
    livarcocc milestoned #4116
  • Jan 31 2019 21:05
    livarcocc commented #4116
  • Jan 31 2019 20:55
    rainersigwald milestoned #4120
  • Jan 31 2019 20:55
    rainersigwald demilestoned #4120
  • Jan 31 2019 20:53
    livarcocc synchronize #4115
  • Jan 31 2019 20:53

    livarcocc on vs16.0

    Bump version to disambiguate wi… Merge pull request #4119 from r… (compare)

  • Jan 31 2019 20:53
    livarcocc closed #4119
  • Jan 31 2019 20:50

    livarcocc on livarcocc-patch-1

    (compare)

  • Jan 31 2019 20:50

    livarcocc on vs16.0

    Adding a vs16.0 trigger Updating to a more general trig… Merge pull request #4118 from M… (compare)

  • Jan 31 2019 20:50
    livarcocc synchronize #4115
  • Jan 31 2019 20:50
    livarcocc closed #4118
  • Jan 31 2019 20:46
    livarcocc milestoned #4120
Michael W Powell
@mwpowellhtx
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.
Michael W Powell
@mwpowellhtx
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.
Kassem Sandarusi
@kassemsandarusi
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.
Joseph Musser
@jnm2
MSBuildLocator lets you list installations and choose one.
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.
Kassem Sandarusi
@kassemsandarusi
Awesome, thanks @jnm2
Michael W Powell
@mwpowellhtx
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 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.
Joseph Musser
@jnm2
Is 'bump assembly versions' sort of like GitVersion? Maybe comparing GitVersion's approach would help.
Michael W Powell
@mwpowellhtx
I don't know, but if the timing is at all similar and <Target /> directed, sure, I'll have a gander. Thanks...
oh, ah, so if we did BeforeTargets="BeforeCompile;CoreCompile" ... That should work then, in either single or multi target cases.
Joseph Musser
@jnm2
Yes, GitVersion is integrated via MSBuild targets
Michael W Powell
@mwpowellhtx
two steps ahead.
:thumbsup:
Michael W Powell
@mwpowellhtx
actually now that I think about it, I think I arrived at DispatchToInnerBuilds due to the fact that "compilation" would happen for each target, which was incorrect. I needed the outer target in the multi use case.
Kassem Sandarusi
@kassemsandarusi
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.
Kassem Sandarusi
@kassemsandarusi
An example, MSBuildWorkspace doesn't support actually altering solutions.
Joe4evr
@Joe4evr
the reason is that the provided object model is intentionally immutable to enable concurrent access/processing
Kassem Sandarusi
@kassemsandarusi
I understand the intentional immutability of the object model, but you can mutate the actual state (files) underneath that the object model represents. At least, you can for documents and projects. But you can't for solutions
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.
Kirk Fertitta
@kfertitta
@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 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.
Kassem Sandarusi
@kassemsandarusi
If I make changes via Roslyn APIs how do I persist them to the actual files on disk? I get the immutability of Solution/Project/Document and how to work with it. When I TryApplyChanges to a Workspace should I expect actual persistence to the files below?
Kirk Fertitta
@kfertitta
The VisualStudioWorkspace does that. It derives from Workspace and has all of the plumbing to translate workspace diffs into VS shell operations. You retrieve the VisualStudioWorkspace within a VS extension using MEF.
Kassem Sandarusi
@kassemsandarusi
Ok so MSBuildWorkspace itself has no ability to persist changes itself. Extensions of MSBuildWorkspace do. MSBuildWorkspace is really just a way of asking MSBuild to parse and build the object models.
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
Kirk Fertitta
@kfertitta
You definitely can't get VisualStudioWorkspace outside of VS, obviously. But, I've only worked with MSBuildWorkspace in read-only mode. It may very well be that it doesn't write.
Gonna peek at the implementation.
Kirk Fertitta
@kfertitta
@kassemsandarusi Actually, if you look at the implementation of MSBuildWorkspace on GitHub, then you do see it overriding base class methods, like ApplyDocumentTextChanged and doing real I/O to make the changes.
Kassem Sandarusi
@kassemsandarusi
Yea I thought that was the case
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?
Kassem Sandarusi
@kassemsandarusi
So what I'm trying to ask is... is there a reason Solutions are not supported well? Are they a pain to maintain libraries for writing to them? Is the ecosystem trying to kill them off?
Kirk Fertitta
@kfertitta
@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.
Kassem Sandarusi
@kassemsandarusi
@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.
Kassem Sandarusi
@kassemsandarusi
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.
Kirk Fertitta
@kfertitta
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.
Kassem Sandarusi
@kassemsandarusi
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.
Michael W Powell
@mwpowellhtx
Hello, which is the target when Nuget packages?
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.
Michael W Powell
@mwpowellhtx
It is rarely just about one target. How about a list of the targets, the order in which they are evaluated? For both multi target and single target builds?
Joseph Musser
@jnm2
@mwpowellhtx I think they are considered breakable private details.