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

WinRT Fixes and UWP Wrapper #1045

Closed
wants to merge 5 commits into
from

Conversation

Projects
None yet
3 participants
@donald-hanson

This is based on the google group discussion: https://groups.google.com/d/topic/openzwave/O74OL4BDrS0/discussion

There are 4 commits each meant to address something interrelated:

  1. add missing command class files and new http related files
  2. HttpClient needed to be updated to compile on WinRT as certain APIs were Win32 only
  3. WinRT SerialControllerImpl was not finding the Z-Stick Gen5 during testing
  4. UWP Wrapper project to expose OZW to C# on UWP platform
@Fishwaldo

This comment has been minimized.

Show comment
Hide comment
@Fishwaldo

Fishwaldo Nov 25, 2016

Member

Question? Is it not possible to use the existing dotNet files for UWP? I'm not a huge fan of having to maintain another wrapper that will most likely get stale and out of date.... :(

Member

Fishwaldo commented Nov 25, 2016

Question? Is it not possible to use the existing dotNet files for UWP? I'm not a huge fan of having to maintain another wrapper that will most likely get stale and out of date.... :(

@Fishwaldo Fishwaldo self-assigned this Nov 25, 2016

@Fishwaldo

This comment has been minimized.

Show comment
Hide comment
@Fishwaldo

Fishwaldo Dec 28, 2016

Member

ping

Member

Fishwaldo commented Dec 28, 2016

ping

@dotMorten

This comment has been minimized.

Show comment
Hide comment
@dotMorten

dotMorten Jan 10, 2017

Member

@Fishwaldo Not with the way you're exposing the .NET library.
If you want that, we need a C SDK with methods exported, and a pure C# managed library on top that calls these exports. We could then use the same .NET library, and just have two build targets for the native C-SDK. This is generally how you would create a cross-platform .NET library that has native dependencies.
I don't think you will get around the need for separate native implementations, since getting access to serial ports are quite different (unless we also abstract that out into a C SDK).

@donald-hanson has actually done a pretty good job at keeping this wrapper as slim as possible and re-using existing implementations internally. So all this really does is expose the same classes that .NET SDK does, but as WinRT ref classes instead. I was actually about to do the same work, when I released Donald beat me to it.

Member

dotMorten commented Jan 10, 2017

@Fishwaldo Not with the way you're exposing the .NET library.
If you want that, we need a C SDK with methods exported, and a pure C# managed library on top that calls these exports. We could then use the same .NET library, and just have two build targets for the native C-SDK. This is generally how you would create a cross-platform .NET library that has native dependencies.
I don't think you will get around the need for separate native implementations, since getting access to serial ports are quite different (unless we also abstract that out into a C SDK).

@donald-hanson has actually done a pretty good job at keeping this wrapper as slim as possible and re-using existing implementations internally. So all this really does is expose the same classes that .NET SDK does, but as WinRT ref classes instead. I was actually about to do the same work, when I released Donald beat me to it.

@dotMorten

Found a couple of building issues with the PR

<PropertyGroup Label="UserMacros" />
<PropertyGroup />
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">
<GenerateManifest>false</GenerateManifest>

This comment has been minimized.

@dotMorten

dotMorten Jan 10, 2017

Member

I found I had to add this here to each configuration to get it building in all configurations (ie same addition to the 5 property groups below this one):

    <IntDir>$(PlatformTarget)\$(Configuration)\</IntDir>
    <OutDir>$(SolutionDir)$(PlatformTarget)\$(Configuration)\$(MSBuildProjectName)\</OutDir>

IntDir isn't strictly necessary, but then it matches OpenZWave project.

Without explicitly defining the outdir, Win32 is going into an odd folder in VS, and that target will fail to build, and I think it's good order to make sure these outdir matches the outdirs of the other project, in case VS ever changes defaults.

@dotMorten

dotMorten Jan 10, 2017

Member

I found I had to add this here to each configuration to get it building in all configurations (ie same addition to the 5 property groups below this one):

    <IntDir>$(PlatformTarget)\$(Configuration)\</IntDir>
    <OutDir>$(SolutionDir)$(PlatformTarget)\$(Configuration)\$(MSBuildProjectName)\</OutDir>

IntDir isn't strictly necessary, but then it matches OpenZWave project.

Without explicitly defining the outdir, Win32 is going into an odd folder in VS, and that target will fail to build, and I think it's good order to make sure these outdir matches the outdirs of the other project, in case VS ever changes defaults.

# Visual Studio 14
VisualStudioVersion = 14.0.25420.1
MinimumVisualStudioVersion = 10.0.40219.1
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "OpenZWaveUWP", "OpenZWaveUWP.vcxproj", "{46641B66-9271-4234-8E8B-1547DEF4BEBB}"

This comment has been minimized.

@dotMorten

dotMorten Jan 10, 2017

Member

Inside here set a build dependency on the static library:

    ProjectSection(ProjectDependencies) = postProject
        {E830F9D6-8173-4B0B-9ECE-CAADFA531B54} = {E830F9D6-8173-4B0B-9ECE-CAADFA531B54}
    EndProjectSection
@dotMorten

dotMorten Jan 10, 2017

Member

Inside here set a build dependency on the static library:

    ProjectSection(ProjectDependencies) = postProject
        {E830F9D6-8173-4B0B-9ECE-CAADFA531B54} = {E830F9D6-8173-4B0B-9ECE-CAADFA531B54}
    EndProjectSection
(
String^ _configPath,
String^ _userPath,
String^ _commandLine

This comment has been minimized.

@dotMorten

dotMorten Jan 11, 2017

Member

I would suggest hardcoding these, or at least provide a simpler overload. The nuget package would always deploy the configs in the same folder, the userPath would always be Windows::Storage::ApplicationData::Current::LocalFolder->Path.

@dotMorten

dotMorten Jan 11, 2017

Member

I would suggest hardcoding these, or at least provide a simpler overload. The nuget package would always deploy the configs in the same folder, the userPath would always be Windows::Storage::ApplicationData::Current::LocalFolder->Path.

@Fishwaldo

This comment has been minimized.

Show comment
Hide comment
@Fishwaldo

Fishwaldo Jan 11, 2017

Member

As noted, my problem is with having "another" independent wrapper is it will bitrot. The .Net wrapper already is bitrotting and lags behind the main C library.

Additionally, pardon my ignorance of the windows platform, but when you say a C-SDK wouldn't the "uwp/src/" and "dotnet/src/" be mainly the same (apart form what you mention, the Serial Port code etc). I'm ok having that library #ifdef etc.

I've actually been tossing up splitting the existing "dotNet" wrapper into its own github repository and asking for a maintainer for it, as I don't really have the experience to maintain it myself. If you or @donald-hanson or anyone else is interested in taking that up, then you can run it anyway you see fit :)

Member

Fishwaldo commented Jan 11, 2017

As noted, my problem is with having "another" independent wrapper is it will bitrot. The .Net wrapper already is bitrotting and lags behind the main C library.

Additionally, pardon my ignorance of the windows platform, but when you say a C-SDK wouldn't the "uwp/src/" and "dotnet/src/" be mainly the same (apart form what you mention, the Serial Port code etc). I'm ok having that library #ifdef etc.

I've actually been tossing up splitting the existing "dotNet" wrapper into its own github repository and asking for a maintainer for it, as I don't really have the experience to maintain it myself. If you or @donald-hanson or anyone else is interested in taking that up, then you can run it anyway you see fit :)

@dotMorten

This comment has been minimized.

Show comment
Hide comment
@dotMorten

dotMorten Jan 11, 2017

Member

To be honest I had thought about forking it, as I don't find the .NET library very easy to use for a .NET developer. I think there's quite a lot that could be done to make it feel more like an API a .NET developer would use. I just don't know how much time I could dedicate. I'm already swamped in maintaining other IoT Libraries (the latest an Iotivity to ZWave wrapper hence why I'm in this thread).

However splitting it in two, might make bit-rot even worse? Would it be more helpful to create some issues here, and perhaps we can help getting it back up to speed issue by issue?

Wrt to the UWP and .NET duplicate code: I think we should be able to create some templates that allows us to re-use the code and just if-def the templates for each platform, so there's just one thing to maintain.

Member

dotMorten commented Jan 11, 2017

To be honest I had thought about forking it, as I don't find the .NET library very easy to use for a .NET developer. I think there's quite a lot that could be done to make it feel more like an API a .NET developer would use. I just don't know how much time I could dedicate. I'm already swamped in maintaining other IoT Libraries (the latest an Iotivity to ZWave wrapper hence why I'm in this thread).

However splitting it in two, might make bit-rot even worse? Would it be more helpful to create some issues here, and perhaps we can help getting it back up to speed issue by issue?

Wrt to the UWP and .NET duplicate code: I think we should be able to create some templates that allows us to re-use the code and just if-def the templates for each platform, so there's just one thing to maintain.

@dotMorten

This comment has been minimized.

Show comment
Hide comment
@dotMorten

dotMorten Jan 11, 2017

Member

Took a second look at @donald-hanson's awesome PR, and compared it to the .NET one: The code is almost identical, but with some key differences. I think it should be doable to make it a common code-base with if-def. That would at least resolve one of your concerns.

Member

dotMorten commented Jan 11, 2017

Took a second look at @donald-hanson's awesome PR, and compared it to the .NET one: The code is almost identical, but with some key differences. I think it should be doable to make it a common code-base with if-def. That would at least resolve one of your concerns.

@dotMorten

This comment has been minimized.

Show comment
Hide comment
@dotMorten

dotMorten Jan 11, 2017

Member

@Fishwaldo Just another thought: If I were to take over the .NET portions of this project, would you be ok with changing the LGPL license of the .NET piece to Apache v2.0?

@donald-hanson And would you be ok with me forking with your PR and start building it up as a proper nuget package, and clean up some of it? (as well as re-releasing that bit under apache). Of course I'd gladly credit you and collaborate on it.

I'd also be ok with MIT license, but I can't get my self to do any significant work under such a restrictive license.

Member

dotMorten commented Jan 11, 2017

@Fishwaldo Just another thought: If I were to take over the .NET portions of this project, would you be ok with changing the LGPL license of the .NET piece to Apache v2.0?

@donald-hanson And would you be ok with me forking with your PR and start building it up as a proper nuget package, and clean up some of it? (as well as re-releasing that bit under apache). Of course I'd gladly credit you and collaborate on it.

I'd also be ok with MIT license, but I can't get my self to do any significant work under such a restrictive license.

@dotMorten

This comment has been minimized.

Show comment
Hide comment
@dotMorten

dotMorten Jan 12, 2017

Member

@Fishwaldo Sorry for keep posting here like a maniac :) If we were to split it into a separate project, I assume you'll still maintain the WinRT project file for building the static library? @donald-hanson made some updates to the project file (added missing files) and a fix in HttpClient and SerialControllerImpl that I think are still critical to go into this repo.

Member

dotMorten commented Jan 12, 2017

@Fishwaldo Sorry for keep posting here like a maniac :) If we were to split it into a separate project, I assume you'll still maintain the WinRT project file for building the static library? @donald-hanson made some updates to the project file (added missing files) and a fix in HttpClient and SerialControllerImpl that I think are still critical to go into this repo.

Fishwaldo added a commit that referenced this pull request Feb 17, 2017

Updated WinRT build to include newly added files (#1096)
* Updated WinRT build to include newly added files, and allowed more serial devices to be discovered.
These changes are cherry-picked from @donald-hanson's PR #1045, but excludes all the parts that adds a new WinRT Dynamic Library.

* Bug fix preventing crash when removing a driver
@dotMorten

This comment has been minimized.

Show comment
Hide comment
@dotMorten

dotMorten Feb 27, 2017

Member

@Fishwaldo Since you now merged the other "simpler" PR that contains a lot of the same changes, this PR might be obsolete, apart from the UWP Sample app.

Have you given it some more thought about moving the .NET and UWP build out to a separate project? I've taken my project pretty far here: https://github.com/dotMorten/openzwave-dotnet-uwp and have recently been getting lots of attention from Microsofts Developer relations.

Note though that I made several breaking changes to .NET to simplify and clean up the API, and also bring the UWP and .NET completely in sync, so code is compatible. I think what's there is much better though.

I would like to release it as a Nuget package too, but don't want to step on your nuget package either.

Member

dotMorten commented Feb 27, 2017

@Fishwaldo Since you now merged the other "simpler" PR that contains a lot of the same changes, this PR might be obsolete, apart from the UWP Sample app.

Have you given it some more thought about moving the .NET and UWP build out to a separate project? I've taken my project pretty far here: https://github.com/dotMorten/openzwave-dotnet-uwp and have recently been getting lots of attention from Microsofts Developer relations.

Note though that I made several breaking changes to .NET to simplify and clean up the API, and also bring the UWP and .NET completely in sync, so code is compatible. I think what's there is much better though.

I would like to release it as a Nuget package too, but don't want to step on your nuget package either.

@Fishwaldo

This comment has been minimized.

Show comment
Hide comment
@Fishwaldo

Fishwaldo Feb 28, 2017

Member

Hi,
Sorry for the lack of noise.... Real life.. ugh...

@Fishwaldo Just another thought: If I were to take over the .NET portions of this project, would you be ok with changing the LGPL license of the .NET piece to Apache v2.0?

ehhh. I'm not the only copyright holder on this code (we don't do any copyright assignment) so technically we need everyone who has contributed to the .Net wrapper to agree to relicense... and I know some of the original authors are MIA. That would be hard..... (but not impossible)

I'm totally fine with you taking over the code... so all that ends up in the original OZW repo is the C++ library... in fact thats my preferred approach.

I can remove the .Net code in the Dev Branch now.... My only concern is there are existing projects that are out there that are dependent upon this interface. If your changes are "breaking", how "breaking" are they? Simple fixes, or more like complete API re-writes?

I'm all for you "doing" it the right way (I saw the coverage you got on the channel9 sites etc), I'm just wondering if there is a way we can ease the migration for existing projects?

Member

Fishwaldo commented Feb 28, 2017

Hi,
Sorry for the lack of noise.... Real life.. ugh...

@Fishwaldo Just another thought: If I were to take over the .NET portions of this project, would you be ok with changing the LGPL license of the .NET piece to Apache v2.0?

ehhh. I'm not the only copyright holder on this code (we don't do any copyright assignment) so technically we need everyone who has contributed to the .Net wrapper to agree to relicense... and I know some of the original authors are MIA. That would be hard..... (but not impossible)

I'm totally fine with you taking over the code... so all that ends up in the original OZW repo is the C++ library... in fact thats my preferred approach.

I can remove the .Net code in the Dev Branch now.... My only concern is there are existing projects that are out there that are dependent upon this interface. If your changes are "breaking", how "breaking" are they? Simple fixes, or more like complete API re-writes?

I'm all for you "doing" it the right way (I saw the coverage you got on the channel9 sites etc), I'm just wondering if there is a way we can ease the migration for existing projects?

@Fishwaldo

This comment has been minimized.

Show comment
Hide comment
@Fishwaldo

Fishwaldo Feb 28, 2017

Member

Also - If you wanted to move your Repo to the OpenZWave Organization (you retain full control etc over the repo) then let me know... I'm only thinking that from a ease of users finding the wrapper - as well as "this is a endorsed, maintained wrapper" perspective... not a "Fishwaldo owns this..." claim on your code.

Member

Fishwaldo commented Feb 28, 2017

Also - If you wanted to move your Repo to the OpenZWave Organization (you retain full control etc over the repo) then let me know... I'm only thinking that from a ease of users finding the wrapper - as well as "this is a endorsed, maintained wrapper" perspective... not a "Fishwaldo owns this..." claim on your code.

@dotMorten

This comment has been minimized.

Show comment
Hide comment
@dotMorten

dotMorten Feb 28, 2017

Member

There aren't huge breaking changes no. I did however change the namespace, since the UWP build isn't a .NET Library (it's a WinRT library), so the namespace is now the more obvious and shorter "OpenZWave". I wanted them to be the same so code is compatible. I also converted some property-like methods into real properties, cleaned up a few enum types, and removed deprecated stuff (Controller commands for instance), and made it more clear that there is only one static instance of the ZWManager, by exposing it as such. Nothing really that major to upgrade your app, and the API is more natural to work with now from a .NET developers point of view.
However yes these are significant changes and you will need to update up your code. The general flow of the app hasn't changed at all, and I should be able to build a fairly short "this is what you need to change" list.
I think the prudent thing to do is give the nuget package a major version increase to follow semantic versioning rules. I do want to do a little more house-cleaning first though, and see if I can't share more code between UWP and .NET so there's less duplication. Some C++ templates might help with that to abstract WinRT and CLI differences, but that's where my C++ skills starts lacking a bit.
I've also added significant amount of XML Documentation, so you get intellisense when using the SDK.

Here's one example of before/after:

before:

using OpenZWaveDotNet;
// ...
var options = new ZWOptions();
options.Create(@"..\..\..\..\..\..\..\config\", @"", @"");
options.AddOptionInt("SaveLogLevel", (int) ZWLogLevel.Detail);
options.Lock();
var manager = new ZWManager();
manager.Create();
manager.OnNotification += OnNodeNotification;
manager.AddDriver(@"\\.\COM5");

now:

using OpenZWave;
// ...
ZWOptions.Instance.Initialize(); //defaults to where nuget deploys config + app local data folder for UWP, "" for .NET
// or  ZWOptions.Instance.Initialize(configPath, userpath, commandline);
ZWOptions.Instance.AddOptionInt("SaveLogLevel", (int)ZWLogLevel.Detail);
ZWOptions.Instance.Lock();
ZWManager.Instance.Initialize();
ZWManager.Instance.OnNotification += OnNodeNotification;
ZWManager.Instance.AddDriver(@"\\.\COM5");

This removes the confusion that there's only one options instance and only one manager instance, but the older API seems to indicate you can create multiple. You can still get a reference to the manager instance (you just can't create more), which means it'll reduce your code changes, since you could just pass that around. ie

var manager = ZWManager.Instance;

The code is the exact same for UWP and .NET (although port id string is naturally different).

The alternative is that you maintain the .NET API as is, and deprecate it in the near future, directing to this newer API.

Member

dotMorten commented Feb 28, 2017

There aren't huge breaking changes no. I did however change the namespace, since the UWP build isn't a .NET Library (it's a WinRT library), so the namespace is now the more obvious and shorter "OpenZWave". I wanted them to be the same so code is compatible. I also converted some property-like methods into real properties, cleaned up a few enum types, and removed deprecated stuff (Controller commands for instance), and made it more clear that there is only one static instance of the ZWManager, by exposing it as such. Nothing really that major to upgrade your app, and the API is more natural to work with now from a .NET developers point of view.
However yes these are significant changes and you will need to update up your code. The general flow of the app hasn't changed at all, and I should be able to build a fairly short "this is what you need to change" list.
I think the prudent thing to do is give the nuget package a major version increase to follow semantic versioning rules. I do want to do a little more house-cleaning first though, and see if I can't share more code between UWP and .NET so there's less duplication. Some C++ templates might help with that to abstract WinRT and CLI differences, but that's where my C++ skills starts lacking a bit.
I've also added significant amount of XML Documentation, so you get intellisense when using the SDK.

Here's one example of before/after:

before:

using OpenZWaveDotNet;
// ...
var options = new ZWOptions();
options.Create(@"..\..\..\..\..\..\..\config\", @"", @"");
options.AddOptionInt("SaveLogLevel", (int) ZWLogLevel.Detail);
options.Lock();
var manager = new ZWManager();
manager.Create();
manager.OnNotification += OnNodeNotification;
manager.AddDriver(@"\\.\COM5");

now:

using OpenZWave;
// ...
ZWOptions.Instance.Initialize(); //defaults to where nuget deploys config + app local data folder for UWP, "" for .NET
// or  ZWOptions.Instance.Initialize(configPath, userpath, commandline);
ZWOptions.Instance.AddOptionInt("SaveLogLevel", (int)ZWLogLevel.Detail);
ZWOptions.Instance.Lock();
ZWManager.Instance.Initialize();
ZWManager.Instance.OnNotification += OnNodeNotification;
ZWManager.Instance.AddDriver(@"\\.\COM5");

This removes the confusion that there's only one options instance and only one manager instance, but the older API seems to indicate you can create multiple. You can still get a reference to the manager instance (you just can't create more), which means it'll reduce your code changes, since you could just pass that around. ie

var manager = ZWManager.Instance;

The code is the exact same for UWP and .NET (although port id string is naturally different).

The alternative is that you maintain the .NET API as is, and deprecate it in the near future, directing to this newer API.

@dotMorten

This comment has been minimized.

Show comment
Hide comment
@dotMorten

dotMorten Mar 1, 2017

Member

@Fishwaldo Ported the WinForms sample over to my repo. Didn't take me very long. For the most part the one namespace chance, and remove the Get...() part of the properties (ie ,GetHomeId() method is now just .HomeId property).
See my commits here which should give you a good idea about the changes:
OpenZWave/openzwave-dotnet-uwp@8d0fa6e

There were a couple more involved changes, because I removed the deprecated functions (controller commands mainly), but other than that pretty straightforward, and cleans the code up nicely

Member

dotMorten commented Mar 1, 2017

@Fishwaldo Ported the WinForms sample over to my repo. Didn't take me very long. For the most part the one namespace chance, and remove the Get...() part of the properties (ie ,GetHomeId() method is now just .HomeId property).
See my commits here which should give you a good idea about the changes:
OpenZWave/openzwave-dotnet-uwp@8d0fa6e

There were a couple more involved changes, because I removed the deprecated functions (controller commands mainly), but other than that pretty straightforward, and cleans the code up nicely

@Fishwaldo

This comment has been minimized.

Show comment
Hide comment
@Fishwaldo

Fishwaldo Mar 20, 2017

Member

Ok. Then for the 1.6 (Dev Branch) can I suggest this:

  1. I drop all .Net and don't add the UWP code you have created. The OZW repository then only contains the C++ Library (for both unix and Windows)
  2. We setup a new Repo and I'll add you as maintainer there. You port/add the .Net and UWP wrappers in that repo.
  3. Figure out a nice way to build the .Net and UWP wrappers by pulling in either the OZW repository or just building against binary versions etc from OZW (I can add a build task to http://bamboo.my-ho.st/bamboo/browse/OZW to build the library on Windows if that helps - Just tell me what you need there)
Member

Fishwaldo commented Mar 20, 2017

Ok. Then for the 1.6 (Dev Branch) can I suggest this:

  1. I drop all .Net and don't add the UWP code you have created. The OZW repository then only contains the C++ Library (for both unix and Windows)
  2. We setup a new Repo and I'll add you as maintainer there. You port/add the .Net and UWP wrappers in that repo.
  3. Figure out a nice way to build the .Net and UWP wrappers by pulling in either the OZW repository or just building against binary versions etc from OZW (I can add a build task to http://bamboo.my-ho.st/bamboo/browse/OZW to build the library on Windows if that helps - Just tell me what you need there)
@dotMorten

This comment has been minimized.

Show comment
Hide comment
@dotMorten

dotMorten Mar 24, 2017

Member

@Fishwaldo I've been prepping my repo for this and I'm on board. Let's do this!

1: Sounds good.
2. OK. We can pretty much just fork my repo straight over there (that way it also maintains history): https://github.com/dotMorten/openzwave-dotnet-uwp
3. That's pretty much already done using a sub-module pointing to open-zwave.

Member

dotMorten commented Mar 24, 2017

@Fishwaldo I've been prepping my repo for this and I'm on board. Let's do this!

1: Sounds good.
2. OK. We can pretty much just fork my repo straight over there (that way it also maintains history): https://github.com/dotMorten/openzwave-dotnet-uwp
3. That's pretty much already done using a sub-module pointing to open-zwave.

@Fishwaldo

This comment has been minimized.

Show comment
Hide comment
@Fishwaldo

Fishwaldo Mar 25, 2017

Member
    • You can transfer your repo into OZW if you want, or I fork it.
Member

Fishwaldo commented Mar 25, 2017

    • You can transfer your repo into OZW if you want, or I fork it.
@dotMorten

This comment has been minimized.

Show comment
Hide comment
@dotMorten

dotMorten Mar 27, 2017

Member

@Fishwaldo Joined the org. It doesn't look like I have access to create new, so I can't fork it over myself

Member

dotMorten commented Mar 27, 2017

@Fishwaldo Joined the org. It doesn't look like I have access to create new, so I can't fork it over myself

@Fishwaldo

This comment has been minimized.

Show comment
Hide comment
@Fishwaldo

Fishwaldo Mar 28, 2017

Member

@dotMorten go to your repository settings and scroll down to "transfer"

Member

Fishwaldo commented Mar 28, 2017

@dotMorten go to your repository settings and scroll down to "transfer"

@dotMorten

This comment has been minimized.

Show comment
Hide comment
@dotMorten

dotMorten Apr 1, 2017

Member

@Fishwaldo It still says I can't do this without the rights to create repositories in the OpenZWave org

Member

dotMorten commented Apr 1, 2017

@Fishwaldo It still says I can't do this without the rights to create repositories in the OpenZWave org

@Fishwaldo

This comment has been minimized.

Show comment
Hide comment
@Fishwaldo

Fishwaldo Apr 5, 2017

Member

@dotMorten try again.... :)

Member

Fishwaldo commented Apr 5, 2017

@dotMorten try again.... :)

@dotMorten

This comment has been minimized.

Show comment
Hide comment
@dotMorten

dotMorten Apr 5, 2017

Member

Done!

Member

dotMorten commented Apr 5, 2017

Done!

@dotMorten

This comment has been minimized.

Show comment
Hide comment
@dotMorten

dotMorten Apr 5, 2017

Member

We can probably close this thread

Member

dotMorten commented Apr 5, 2017

We can probably close this thread

@Fishwaldo

This comment has been minimized.

Show comment
Hide comment
@Fishwaldo

Fishwaldo Apr 5, 2017

Member

Ok. Last Question: I can drop the dotNet directory now (in the Dev Branch) right?

Member

Fishwaldo commented Apr 5, 2017

Ok. Last Question: I can drop the dotNet directory now (in the Dev Branch) right?

@dotMorten

This comment has been minimized.

Show comment
Hide comment
@dotMorten

dotMorten Apr 5, 2017

Member

I'd say so, including sample. The WinForms sample has been fully ported and works, and I believe all functionality has been moved over. I did remove some obsolete/deprecated members.

Member

dotMorten commented Apr 5, 2017

I'd say so, including sample. The WinForms sample has been fully ported and works, and I believe all functionality has been moved over. I did remove some obsolete/deprecated members.

@Fishwaldo

This comment has been minimized.

Show comment
Hide comment
@Fishwaldo

Fishwaldo Apr 5, 2017

Member

Boom. Gone. Thanks!

Member

Fishwaldo commented Apr 5, 2017

Boom. Gone. Thanks!

@Fishwaldo Fishwaldo closed this Apr 5, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment