2 replies to this topic

[NameOfTheDragon]

I mentioned this idea in another thread and I've been thinking about how to make it work. Already today I wanted to deploy a new project to my Netduino Plus 2, and it fails to run because I've got the 'debug' firmware flashed. Having to flash the firmware all the time will be a major pain and I'm even more convinced that NuGet is the way to deliver this...

 

I have forked the source code and looked into making a NuGet package. It would be relatively straightforward except for one thing: conditional compilation.

 

Is there no better way to handle the link layer than conditional compilation flags? What if I want to have more than one network interface? Currently it seems to be impossible because the link layer is essentially hard coded via conditional compilation flags.

 

Since this is managed code, there ought to be better ways of handling this, perhaps using reflection to detect a marker interface or a custom attribute?

 

If that could be achieved, then I think it would be simple to produce a NuGet package for each link layer implementation, each of which would depend on another package containing the network layer.

 

I think there are a number of advantages to this approach. If SecretLabs could consider how to get rid of the conditional compilation, then I would be very happy to produce a build for the NuGet packages.

 

Best regards,

Tim Long

[Chris Walker]

Hey Tim,

I mentioned this idea in another thread and I've been thinking about how to make it work. Already today I wanted to deploy a new project to my Netduino Plus 2, and it fails to run because I've got the 'debug' firmware flashed. Having to flash the firmware all the time will be a major pain and I'm even more convinced that NuGet is the way to deliver this...

Ah, yes. The DEBUG firmware is really only meant for debugging the network stack. We did architect Netduino.IP to support runtime deployment scenarios--but officially supporting runtime deployment didn't make the v1.0.0 feature cut list. That said...it's totally possible.

I have forked the source code and looked into making a NuGet package. It would be relatively straightforward except for one thing: conditional compilation.

Is there no better way to handle the link layer than conditional compilation flags? What if I want to have more than one network interface? Currently it seems to be impossible because the link layer is essentially hard coded via conditional compilation flags.

Since this is managed code, there ought to be better ways of handling this, perhaps using reflection to detect a marker interface or a custom attribute?

I'm definitely open to your implementation thoughts on this. Right now we use conditional compilation (consistent with how a lot of other things are handled in the NETMF BSP build process), but there are certainly other options. We just need to keep the implementation clean. What are you implementation thoughts here?

Chris

[NameOfTheDragon]

Chris, I started looking into it and my first thought is, since there is an ILinkLayer interface, would it be possible to dynamically discover implementations of that interface using reflection? I ran into a brick wall trying to work out all the various 'invokes' that are going on and I'm not sure whether simply enumerating all the types in the application domain would discover these interfaces.

 

I started along the lines of:

    internal class LinkLayerDiscovery
        {
        /// <summary>
        ///     Discovers the link layer implementations.
        /// </summary>
        /// <returns>
        ///     An array of types implementing <see cref="ILinkLayer" />. If no types are discovered, the array will
        ///     contain zero elements.
        /// </returns>
        public static ILinkLayer[] DiscoverLinkLayerImplementations()
            {
            var assemblies = AppDomain.CurrentDomain.GetAssemblies();
            ArrayList discoveredTypes = new ArrayList();
            foreach (var assembly in assemblies)
                {
                var assemblyTypes = assembly.GetTypes();
                foreach (var candidateType in assemblyTypes)
                    {
                    var implementedInterfaces = candidateType.GetInterfaces();
                    if (Array.IndexOf(implementedInterfaces, typeof (ILinkLayer)) >= 0)
                        {
                        discoveredTypes.Add(candidateType);
                        }
                    }
                }
            return (ILinkLayer[]) discoveredTypes.ToArray(typeof (ILinkLayer));
            }
        }

...but then ran out of time and had to leave it for the time being. I'm not yet in a position where I can test this so this was very much only my first exploratory stab. I will return to it when I can though.

 

I noticed that the network layer is essentially supplying the hardware configuration details (e.g. SPI bus address) to the link layer and that is a speed bump for this approach. We can't know how to configure something that we've dynamically discovered. The network layer is acting as a sot of "composition root" and it seems a bit odd for the network layer to know about hardware details. I'm not sure whether it makes more sense to move hardware details into the link layer itself. That goes somewhat against the dependency inversion principle, but I can't see where else the 'composition' could realistically be done. I'm afraid my knowledge of NetMF internals is a little bit thin and the time investment it would take for me to come up to speed is probably much more than I can afford.

 

Regards,

Tim Long