Command-line interface (CLI) #35
Comments
|
First step is to choose command-line library. My suggestion is System.CommandLine from corefxlab. Any feedback is welcome... |
|
Is there a sense to send full files paths as arguments? Nowadays their short names are hard coded and documented. So why not to send directory path? |
|
Basically I agree. It makes sense to expect But what if UPDATEI've got half way through implementation, and I realized that I want to change the syntax. Before: one Before: build+run combination for F5 debugging was specified as
|
|
One doubt: I'm sure want to test the CLI, but should I do unit testing, or system testing? Meanwhile I prepared some infra for unit testing the CLI, but I'm not sure it is the best approach... |
|
I came to conclusion that unit testing the CLI doesn't worth effort and complexity it adds. In the last commit to #37, I got rid of unit test project and |
|
A problem. While the CLI is going to be an awesome tool for deployment... it doesn't resolve our current issue #32 for F5 debugging in Visual Studio: In my implementation of Now,
It looks like the best approach for F5 debugging is load modules from where they were compiled. I know we had problems there, so we opted to bring all binaries together by copying. Maybe we should attack that issue again -- maybe like this: AssemblyLoadContext.Default.Resolving += this.OnResolve;I found it here: |
|
So, how many modes/scenarios/ways do we have/plan for now(release/debug directories and packages)? |
|
Why not to add to "run" command new argument which will tell what to do before - publish or copy. This way we can use copy for developing and publish for integration tests and deployment? |
|
My current vision is as follows:
|
|
OK. So we are good again. |
|
In deployment, there is only one folder to search -- the publish folder. For F5 debugging, I assume certain structure of solution folders. Currently, I assume that all projects reside in folders named after their assemblies, in immediate subfolders of the solution folder. This has to be extensible, so that a concrete application will be able to plug in its own structure. UPDATE: I think we can inspect solution structure automatically through SLN and CSPROJ (reusing Microsoft APIs for that, of course). |
|
The last problem with F5 debugging is locating assemblies from NuGet packages. I can just go to
All these lead me to conclude that I don't want to write that logic. It is already written. I only have to figure out how I can reuse it. Currently looking through https://github.com/NuGet/NuGet.Client, https://github.com/dotnet/cli, and https://github.com/Microsoft/msbuild. |
|
We can also ask our users to do publish at least once, but that's ugly; every time they'll add another package reference, they'll need to do publish again; and then we'll answer their issues, telling them they forgot to do so... |
|
Progress in locating assemblies from NuGet packages. MSBuild has a target for that, named This target in turn uses a task class named If I use necessary MSBuild packages from NuGet, I can run that task in-process from the CLI. Like this: http://codefocus.blogspot.co.il/2008/10/running-msbuild-tasks-programatically.html |
|
Good news: the ResolvePublishAssemblies task indeed does what we need. Meanwhile I figured out how to run it with MSBuild. With the following project file p1.proj: <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<UsingTask
TaskName="ResolvePublishAssemblies"
AssemblyFile="C:\Program Files\dotnet\sdk\1.0.0\Sdks\Microsoft.NET.Sdk\build\..\tools\netcoreapp1.0/Microsoft.NET.Build.Tasks.dll" />
<Target Name="Build">
<ResolvePublishAssemblies
ProjectPath="C:\Home\NWheels\Source\NWheels.Injection.Adapters.Autofac\NWheels.Injection.Adapters.Autofac.csproj"
AssetsFilePath="C:\Home\NWheels\Source\NWheels.Injection.Adapters.Autofac\obj\project.assets.json"
TargetFramework=".NETStandard,Version=v1.6">
<Output TaskParameter="AssembliesToPublish" ItemName="ResolvedAssembliesToPublish" />
</ResolvePublishAssemblies>
<Message Text="%(DestinationSubPath)=@(ResolvedAssembliesToPublish)" Importance="high" />
</Target>
</Project>the command: produces the following output: From here I easily build a dictionary of assembly file path by assembly name. In the |
Not the way I wantedI've abandoned attempts to re-host ResolvePublishAssemblies in-process inside the CLI, as there is no clear line in available NuGet packages. Another intention of mine was to use Roslyn's MSBuildWorkspace to inspect SLN files and correctly determine location of module projects. I've abandoned that too, because it isn't yet available in NETStandard (dotnet/roslyn#17974). Cutting edge is bleeding edge.... For nowTo determine location of module projects, I assume simple flat solution structure:
To locate all dependency assemblies, I will generate .PROJ file and run MSBuild command as shown in provious comment. I will intercept standard output and parse assembly name/path pairs into a dictionary. |
Factual implementation summaryThis comment summarizes design and implementation details as of the end of work. Command:
|
Create command line interface that will allow invocation of a pluggable set of commands.
The implementation logic of commands can be either coupled or decoupled from the CLI (this is a question; as for Unix philosophy, the CLI is the master).
Currently, we need two commands:
or combination of both:
The text was updated successfully, but these errors were encountered: