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

Refactor Subprocess Structure #438

Merged
merged 5 commits into from May 18, 2017

Conversation

RichiCoder1
Copy link
Member

This PR accomplishes two major things:

  • It removes the last vestiges of the old style way of how we were doing a number of things in Gui behind the scenes. Also cleans up our async primitives to use the seriously high quality VS.Threading package.
  • Replaces the buggy and ill convinced WAMP IPC protocol with a much more solid WCF IPC layer. Mostly for my santity, but it has had the nice side effect of crashing less and being ever so slightly faster.

Other things of note:

  • I redid how we're copying Subprocess into Gui's output. It's much more sane now, (and gets rid of an app.config issue that was there previously). It also means that Main no longer references Subprocess, but instead a shared project to get Dtos.
  • ChocolateyGui (main) no longer has a dependency on chocolatey.lib (ha). All the choco specific bits have been abstracted and contained in Subprocess.

Lastly, one thing that @ferventcoder and I will both appreciate, you can now start ChocolateyGui.Subprocess before, and independent of, ChocolateyGui. This makes it muuuuch easier to debug Subprocess as you can just set both projects as startup projects in VS (with Subprocess starting first), allowing you to simultaneously attach to both.

Richard Simpson added 3 commits May 13, 2017 21:47
Moves models into a shared project, and copys ChocolateyGui.Subprocess using copy rather than the previous (error prone) reference method.
@RichiCoder1
Copy link
Member Author

RichiCoder1 commented May 14, 2017

AppVeyor is angry w/ me because of cake-contrib/Cake.Recipe#97 (of which the short term fix will like be to just stop using a shared project and switch to class lib)

@ferventcoder
Copy link
Member

I'm all about fixing stuff. Let me take a looksy

public bool IsInstalled { get; set; }

[DataMember]

Copy link
Member

Choose a reason for hiding this comment

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

looks like extra lines inserted here. Issues with flipping this away or to UTF8 usually causes this.

public bool Successful { get; set; }

public IReadOnlyList<string> Messages { get; set; } = new string[0];
[DataMember]
public string[] Messages { get; set; } = new string[0];
Copy link
Member

Choose a reason for hiding this comment

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

So it has to be an array? Can't be a List<string>? (I'm pretty sure IList won't work here).

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 honestly don't know haha. It was yelling at me for other things. Will try again.

return hashCode;
}
}
}
Copy link
Member

Choose a reason for hiding this comment

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

Why did you need to implement this? I'd prefer using it directly out of chocolatey.dll.

Copy link
Member

Choose a reason for hiding this comment

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

Unless it is being internalized, which I think we fixed a long time ago.

Copy link
Member Author

Choose a reason for hiding this comment

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

Nope, this was because I pulled chocolatey.lib out of chocolateygui (so it's only the in the subprocess). However, there's 0 reason I can't just put it back, especially since I'm just using a model.

<Reference Include="Nito.AsyncEx, Version=4.0.1.0, Culture=neutral, processorArchitecture=MSIL">
<HintPath>..\packages\Nito.AsyncEx.4.0.1\lib\net45\Nito.AsyncEx.dll</HintPath>
<Reference Include="Microsoft.VisualStudio.Threading, Version=15.3.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
<HintPath>..\packages\Microsoft.VisualStudio.Threading.15.3.20\lib\net45\Microsoft.VisualStudio.Threading.dll</HintPath>
Copy link
Member

Choose a reason for hiding this comment

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

Weird name...

Copy link
Member Author

Choose a reason for hiding this comment

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

Suprisingly, it's well names. It the Microsoft Visual Studio Team's threading library. It's actually really awesome (hence why I swapped Nito.AsyncEx with it.)

<package id="System.ValueTuple" version="4.3.1" targetFramework="net452" />
<package id="WampSharp" version="1.2.5.27-beta" targetFramework="net452" />
<package id="WampSharp.Fleck" version="1.2.5.27-beta" targetFramework="net452" />
<package id="WampSharp.NewtonsoftJson" version="1.2.5.27-beta" targetFramework="net452" />
Copy link
Member

Choose a reason for hiding this comment

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

That really reduced some dependencies!!

Copy link
Member Author

Choose a reason for hiding this comment

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

That was 90% of the reason for this change. WampSharp just had some many superflous dependencies and issues.

}

_progressService.WriteMessage(message.Message, powerShellLineType);
});
Copy link
Member

Choose a reason for hiding this comment

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

You don't need any of this now? I'm guessing you have a logger set up.

{
Logger.Fatal(ex, "Failed to create client channel to server.");
throw;
}
Copy link
Member

Choose a reason for hiding this comment

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

👍

}

_progressService.WriteMessage(message.Message, powerShellLineType);
}
Copy link
Member

Choose a reason for hiding this comment

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

And there it is.

foreach (var feature in features)
{
Features.Add(feature);
}
Copy link
Member

Choose a reason for hiding this comment

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

Optimization?

Copy link
Member Author

Choose a reason for hiding this comment

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

Actually could be optimized further. I don't what library I pulled in had it, but ObservableCollection (which backs Features, Settings, and Sources on this page) doesn't have an AddRange, so I had to fall back to good old fashion add.

Copy link
Member

@ferventcoder ferventcoder left a comment

Choose a reason for hiding this comment

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

I'm mostly 👍 - if you've played with this and everything works appropriately, then I'm all 👍 . Once this is in I can add in the fixes for the background service checks.

@RichiCoder1
Copy link
Member Author

I'll address the interface issues in a later PR. Should be good to go.

@RichiCoder1 RichiCoder1 merged commit 6bc3ab1 into develop May 18, 2017
@RichiCoder1 RichiCoder1 deleted the feature/Refactor_Process_Structure branch May 18, 2017 16:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants