Csproj replacement for ProjectModel

[ThadHouse]

I had a new verb I was working on creating, and was using the ProjectModel namespace to get the project and the workspace. I noticed that this has been removed, and most of the functionality I can find is now a part of the dotnet verb, however the utilities in that application are not being published to NuGet. What is the now recommended way to get the project and all dependencies from a custom verb? Adding an msbuild task for what I wan't to do is not an ideal solution for my project. I tried looking into the existing issues, and could not find any updates, and I could not find any updated documentation online either.

[TheRealPiotrP]

@ThadHouse CLI's use of ProjectModel was replaced by a combination of MSBuild targets, MSBuild tasks, and the Evaluation namespace. I suspect the last is what you're after. Take a look at cli/src/dotnet/MsbuildProject.cs for some examples on how we use it.

[ThadHouse]

I took a look at that class, and even copying it to my own project it kept throwing an exception saying it could not find the SDK target trying to load the project. I'll keep looking though. However, is there any chance that class, and some of the other command line stuff gets published into its own package, or is the suggestion just to copy it all into our code?

The exact exception I get is an InvalidProjectFileException, stating The imported project \"C:\\Program Files\\dotnet\\Sdks\\Microsoft.NET.Sdk\\Sdk\\Sdk.props\" was not found. I'm using the evaluation from the 2.0.0 alpha of Microsoft.DotNet.CLI.Utils. Is that right?

[TheRealPiotrP]

@ThadHouse

[TheRealPiotrP]

@ThadHouse I'm re-opening and moving to backlog for the moment. I doubt we'll get to this in 1.0.0 or 2.0.0 but you're right that there is likely a need to pursue. I'm not excited to pursue this until we better understand how this dll would be used, which only time will tell. We rushed on Microsoft.DotNet.Cli.Utils which turned into a grab-bag of features and does not provide a great developer experience.

The issue you're facing is a real one. You need access to the CLI's MSBuildSdksPath environment variable which is currently intentionally only exposed to code running inside of the context of the CLI. We're keeping it inside of our context because the content comes from different places if running from standalone msbuild or from Visual Studio. We don't yet have a model that enables you to successfuly write tools that work in all of these contexts unless they're structured as MSBuild tasks.

What blocks you from implementing your tool as a task? Understanding the gap will help with design once we get to this...

[ThadHouse]

That's good to hear. I found ways to work around all my issues since I'm only targeting .NET 4.5 and not .NET Core for now. But I know when I change to Core I'm going to need more msbuild access. But that can definitely wait

My issue with the tasks were 2 things.
The first was more of a design functionality issue in my code. I was originally thinking I would need shared data between a before build task, the after build task, and in my verb runner script. However after some more thought I determined this wasn't really an issue, and I could implement everything I needed the build information for in just a post build task. I still would need to pass like 15 properties to my task, since if my understanding is right you can't pass full objects, but that's not as big of a deal.
The second issue I have is a much bigger one that maybe you can help with. https://docs.microsoft.com/en-us/dotnet/articles/core/preview3/tools/extensibility
Looking at the docs here, it says I can use NuGet to package my task, however it says it will be added as an In Graph dependency of the project. I created a test task, which was set to be a .netstandard 1.6 library. However the executable I am adding it to is a .NET 4.5.2 project. When trying to add the dependency on the task to the project, it fails saying that .netstandard 1.6 is not compatible with net452. Looking at the example here https://github.com/dotnet/MVPSummitHackathon2016 I see that the example task and the output executable were netstandard1.6 and netcoreapp1.0, which do work together. If the task does really get added to the dependency graph, then it is not usable for my purpose since it's my frameworks don't match.

[ThadHouse]

As for what I would want from the DLL in the future, here is the list if that helps.

• List of TargetFrameworks
• List of RuntimeIdentifiers
• Output exe/library name
• Build output directory
• List of locations where I can find all the runtime dependencies (This is actually the one I know is going to be the hardest, since with core projects these do not get copied to the output directory except on publish).

I think that's all I'm going to need. I know looking at this, I'm probably going to need to do a full msbuild task, so what I was planning on doing probably isn't possible with just the csproj file.

One more thing I would like not related to msbuild would be all the things needed for the CommandLineApplication class, and the CommandBase stuff. All of that is really nice to work with, and even though its easy to copy, it'd be nice to just need a dll to use that stuff.

[TheRealPiotrP]

@ThadHouse passing multiple parameters to tasks should be manageable through targets. When you write the task you will include in your nuget package for the task a target. That target is responsible for invoking the task. If you need to do wire-up, you can handle it there and keep it hidden from your users.

If you implement the tool as a task, the concern of matching frameworks goes away. You'll be running in the msbuild process and be unaffected by the output project.

Is your project public? I'd be curious to take a look and help structure the functionality as a task. It might be a good example for others.

The other perk you'll see is that the task will be cross-plat and cross-IDE [VS, VSCode, CLI, VS for Mac]. I think this is going to be the right model for tools that require access to the sorts of properties that you are looking for. If there are gaps, I'd like to understand and fix them instead of propagating a separate extension model which won't work in the IDEs.

[ThadHouse]

Yes, it is public. It's basically a reimplementation of an old VS extension I have. The extension can be found here https://github.com/robotdotnet/FRC-Extension and the CLI stuff I am working on can be found here https://github.com/robotdotnet/FRC-CLI

Basically my task is opening up an SSH connection to an external device, checking some things on that device to make sure its set up properly, and then deploying the entire build output to that device.

The framework issue is still confusing to me though. I copied the task from here https://github.com/dotnet/MVPSummitHackathon2016/tree/master/SampleTargets.PackerTarget and tried changing the name to get it to match mine. Packed it up in a NuGet package like the docs there suggest, and tried adding it to a .net4.5.2 project, and it gave me the framework version issue. If I tried adding the exact target from that repo it would work in the 4.5.2 project, but I changed literally anything in the target, either the name, or what it does, and it would no longer add to my project, and tell me the frameworks are invalid.

[dasMulli]

@ThadHouse a way around writing msbuild tasks at the moment is to add a custom extension target file to the project by placing it in the obj folder and calling a target defined inside it.
This is what dotnet ef does (using this target). There is also a nice blog write-up of how it works at http://www.natemcmaster.com/blog/2016/12/26/project-evalutation-cli-tool/

[livarcocc]

Closing this issue as we do not have plans to provide APIs out of the CLI repo and have since stopped shipping Cli.Utils.