Skip to content
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

CLI #37

Merged
merged 13 commits into from
Apr 6, 2017
Merged

CLI #37

merged 13 commits into from
Apr 6, 2017

Conversation

felix-b
Copy link
Member

@felix-b felix-b commented Mar 29, 2017

This PR is for task #35. It will include the skeleton of the CLI program and implementation of the service command.

@felix-b felix-b self-assigned this Mar 29, 2017
@felix-b
Copy link
Member Author

felix-b commented Mar 29, 2017

first run of nwheels service -h

image

@felix-b felix-b requested a review from ILyaIL83 March 29, 2017 13:39
felix-b added 3 commits March 30, 2017 07:13
…d ICommandContext to allow unit testing ; added unit test project NWheels.Cli.UnitTests.
felix-b and others added 9 commits April 2, 2017 04:35
- Run determines module assembly search directories
- BootConfiguration extended with list of assembly search directories
- MicroserviceHost looks up assemblies in search directories if specified in BootConfiguration
…(replaced AssemblyDirectories added earlier).
…all to IWebHost.Run() was blocking, replaced with IWebHost.Start().
…used deadlock, because output buffer was not read while waiting for process to finish.
…launchSettings.json (project debug settings) doesn't have to change per developer.
@felix-b
Copy link
Member Author

felix-b commented Apr 5, 2017

Done. Ready for review/merge. See https://github.com/felix-b/NWheels/issues/35#issuecomment-291737360 for final info.

@felix-b felix-b changed the title WIP - CLI CLI Apr 5, 2017
Copy link
Collaborator

@ILyaIL83 ILyaIL83 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So as I see it, bitness is critical, the rest is minor or should be kept in mind and/or covered by integration tests.
What do you think?
I haven't tested Cli in depth, but it looks very useful.

ref _environmentFilePath, requireValue: false,
help: "path to environment XML file to use");

syntax.DefineOption("n|no-cli",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why to call publish in development mode at all?(I see that RunCommand calls publish with no-cli)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is a shortcut. Instead of calling nwheels publish on source folder, and then nwheels run on published folder, you can call nwheels run on source folder, and it will do both things in one command.

return false;
}

var projectElement = XElement.Parse(File.ReadAllText(projectFilePath));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is very fragile path. Nobody can guarantee that in the future project file's structure won't be changed.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I mentioned in https://github.com/felix-b/NWheels/issues/35#issuecomment-291737360, in the Current Limitations section, we are waiting for Roslyn project system to be fully ported and consumable from .NET Core applications. Then we can use Roslyn to inspect solution and project files. Roslyn project system provides such classes as this: http://source.roslyn.io/#Microsoft.CodeAnalysis.Workspaces.Desktop/Workspace/MSBuild/MSBuildWorkspace.cs

}
else
{
LogWarning($"Assembly directory pair could not be parsed: {line}");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I run Cli project, I've got little bit strange log decoration, despite service went up.
StrangeOutput.txt

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is unexpected output from dotnet msbuid command. I expect to get lines in the format "assembly.dll=path/to/assmebly.dll", but instead I get "Welcome to .NET Core!". Something goes wrong. Can you write me the command you ran, and what was the current folder?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we weren't able to consistently reproduce it, let's see when it pops up again. If it will, we will open a bug,

@@ -0,0 +1,396 @@
using NWheels.Cli.Publish;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Solution configuration: Debug
Solution platform: Any CPU
Application arguments: run NWheels.Samples.FirstHappyPath --no-publish
I've started Cli with Ctrl+F5(not in debug) and it runs in 32 bit(C:\Windows\SysWOW64\cmd.exe).
While 64 bit default cmd is from C:\Windows\System32.
So, the question is can we run in 64 and why it's in 32?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. I didn't take that into account. I think we can stick to 64bit. Probably define Platform=x64 for NWheels.Cli project. I'll check that.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I checked -- as I thought, it depends on Platform setting of NWheels.Cli.

Visual Studio is a 32 bit process, and it will run programs in 32 bit if their platform is "x86" or "Any CPU". If the platform is "x64", it will run the program in 64 bit with both F5 and Ctrl+F5.

I have set the platform of NWheels.Cli to x64.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's track it in #39 -- we have to discuss it.


foreach (var directoryProbe in _assemblyMap.Directories)
{
var filePathProbes = new[] {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need *.exe and *.so?

Copy link
Member Author

@felix-b felix-b Apr 5, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. We probably don't.

In order to get .exe, the project needs to be published as a self-contained application. Our code runs on folder where the project compiles to, Compile and publish are two different operations in .NET Core. Compile never produces .exe. So, looking for .exe is redundant.

Regarding .so, these are assemblies specific to Linux. They belong to runtime-specific assemblies, which I cannot reliably map anyways. I've put this comment in code:

//TODO: skip assemblies that come from runtimes/<RID>/... (RID = Runtime IDentifier, e.g. win7-x64, debian-x64)
//      since such assemblies are listed multiple times (per each RID), 
//      and we don't filter by any specific RID, it is unreliable anyway
//      + those assemblies don't seem to ever arrive to AssemblyLoadContext.Resolving

Thus, looking for .so is redundant.

I will remove relevant bits of code.

@@ -36,7 +36,7 @@ public override void MicroserviceActivating()
})
.Build();

_host.Run();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With Run command thread was blocked as I understand. Thanks for fix.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're welcome :)

@@ -1,7 +1,7 @@

Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 15
VisualStudioVersion = 15.0.26228.4
VisualStudioVersion = 15.0.26228.9
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have 15.0.26228.10 version of VS :) I think you also, so does it mean they haven't changed format?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It means I didn't install last VS2017 update on my home desktop :) Will do that today.

@@ -0,0 +1,81 @@
using System;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I run Cli without any parameters it crashed with:
"error: missing command
Press any key to continue . . ."
It seems Cli itself should gives/takes -h|--help command when there is no any.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah. You're right. Will fix that.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll track it in #38. The fix will be part of PR #33.

@felix-b felix-b merged commit d1fdf04 into master Apr 6, 2017
@felix-b felix-b deleted the pr-cli branch April 6, 2017 05:27
@felix-b felix-b added the gen1 label Mar 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants