Remove referenced projects that isn't in the project

[eiaro]

Reference to local projects will make project hard to maintain. Either include it in the project, or separate it out as a own project and publish a Nuget for it.

[Mr-Markus]

Which Project reference do you have, that is not contained in the repository?

Do you mean unpi-net which is referenced as a submodule?

I am not really happy about submodules and would prefer a NuGet Package with SourceLink, but i haven't implemented it, yet.

[eiaro]

You probably wouldn't use this project unless you use unpi-net or another hardware interface, so in my mind they belong together. If another hardware interface is needed, it should be added accordingly.

A end user should probably only need to do:

var zigbeeInt = ZigbeeNet.CC2531(); // Static function to initialize the interface
zigbeeInt.PacketReceived += MyPacketHandler;
zigbeeint.Send(amazing stuff);

If the UNPI is intended to be a separate project for other implementations, then it should be moved out as it's own project when the need arise.

A cool feature is to include the possibility of using the interface over a TCP connection (serial to TCP) in addition to regular serial port.

[Mr-Markus]

I understand and the idea sounds goog. But you can use unpi-net for other Projects, too. Zigbee is just one possible solution. Other would be e.g. Bluetooth

See: http://processors.wiki.ti.com/index.php/Unified_Network_Processor_Interface

So i would prefer an own project for it. And because of that we have a reference on ZigbeeNet. But the idea of an interface for different Zigbee Hardware Interface was already an idea of mine. We can add a new issue in ZigbeeNet for this :-)

Do you mean that unpi-net would be better as a REST Service than a own library? Or what do you mean?

[eiaro]

Yes, the UNPI can be used for other projects, but currently it is only used here. So pragmatically you should include it in the project, not make a separate project (repository) for it.

At a later stage you may take it out of this project and make it a separate project, but when you do, it should be testable that it doesn't break any implementations (this project). It's a common problem when working on a project that is divided into parts; when do you split them up. Answer is usually when needed.

In the end, by having it in the project, if only temporary, will make development easier and refactoring has less chance of breaking.

[Mr-Markus]

Yes, you are right. Tipically Problems you have during new development.

The unpi-net library is now at a Version that is running and don't need further development to run ZigbeeNet. We are now at the point where logic needs to be implemented inside ZigbeeNet, because sending data to the TI Hardware via unpi-net is running.

So i think it that the next step would be to create a nuget package for unpi-net and reference it in ZigbeeNet.

[Mr-Markus]

I removed the submodule and replaced project reference of unpi-net with it's new NuGet package.