ErikN

I've had pretty good success with running WIndows inside VirtualBox. After you've connected the board you need to go into VirtualBox settings, USB and add a filter for the Netduino device. This should cause the Netduino to automatically (re)connect to the VM instance when it is plugged in / rebooted.

 

Sometimes a deployment will fail or time out. Usually I can just right-click on the VirtualBox USB indicator in the status bar and click the Netduino device to disconnect it and do that again to reconnect it before trying to deploy again.

 

It's not as smooth as just using a native Windows environment but it's not bad either.

I'm running the wcf service in visual studio debug mode in visual studio 2012.
I'm running the netduino in debug mode in visual studio 2010.

Both on same computer.

While your VS instances are on the same computer, you Netduino is an external device. Usually VS doesn't not allow remote clients to connect to services it is hosting directly. I'm unsure if this is a setting that can be changed in Visual Studio directly.
I know you mentioned unblocking ports - is this from within VS or a firewall on your host computer? If it's a firewall, then VS itself is denying the connection attempt since it's coming from a client external to itself.

I really test this you'll have to publish your WCF service to an IIS virtual application or see if Visual Studio can be set to permit external connection requests.

I am actually going to disagree with this one. There is a lot of value to this being discussed on an open thread. Most likely there are other devs that can learn from it and avoiding having the same issues in something they are working on.

tt.

I'm going to disagree with your disagreement.
This discussion isn't really for devs - it's for module developers. There is a different effort being made on establishing best practices and, I think, write up a Module Builders Guide which would benefit from anything learned during this process.

This particular discussion is just noise on the original question now.

Ulrik,

I felt that your reaction was offensive and unfair. I'm only interested in one thing: getting our users unblocked asap and for issues such as this one to never repeat themselves in the future.

Aside from how you perceived his words, it sounds like we had an easy, quick answer to unblock your users. Don't upgrade to 4.2.1 until this bug is worked out. Bugs happen. In all industries. This is not unexpected and to continue to claim this is errant behavior is disingenuous.

Software releases generally follow a process which involves regression testing to mitigate potential user impact when changes are introduced. It's a reasonable thing to ask if regression-testing occurred because it is a standard best practice in our industry. No one should be offended by that and I am confused as to why anyone would perceive my question to be a wrongful attempt at keeping anyone waiting.

It sounds like they did do quite a bit of work to ensure the update did not change the way the spec was designed. From my observation it looks as though the driver were written in such a way that it happened to work through a bug or fluke. It is out of spec. Of course it could break as the spec evolves if it isn't conformant. Please don't put the weight of, what appears to be, a poor implementation of the spec on the designers of said spec. It's just divisive and won't win you any favors in trying to get problems resolved.

This has moved well beyond anything of benefit of the average user at this point. I'm sorry you feel as though you're going to have to move mountains to make your driver work as it should but it's just a bit of software. And there's time - there's no absolute need for your users to move to 4.2.1 immediately. They're in good hands while this gets worked out. Take the time to analyze what went wrong, read over the spec and recommendations on how to implement and mull over how your interactions could change in the future to be more conducive to problem solving and be just all around a bit more civil.

Bon chance!

As you can see in this thread, one of your customers have no issues figuring out that your modules is not ready for the new firmware yet, and i'm sure they will be soonish, as i can see your are offered all kinds of help on this issue, but i fail completely to see why other projects should wait.

I picked up on that as well. I wanted to escort her out of the thread and thank her for her bug report!

New software usually has some known errata upon release. Most of the times things are found after. This looks like one of those times. I think this might have escalated a bit beyond reason here - though I agree a minor build should not introduce any contract changes, it's hardly damaging at this point. I think, given the report and the reproducibility maybe it would be good to put a notice on the product page(s) saying there is a known issue with this firmware release and that it's not recommended for people using those modules.


In the mean time it seems Chris is offerring resources to help correct the problem. It looks like he's already pointed out some suggestions as to possible issues or at least some best practices. I'd love to see these tidbits incorporated into the Module Builders guide (whatever the actual title or form it might take) but in the mean time I'd say take a step back for the moment. It doesn't really seem like a big deal. If people are using these modules successfully, they wouldn't upgrade to the newest firmware just for giggles. If they did, I'd say they'd have the capability to downgrade back to the last working version just as easily. If this isn't the case, it doesn't seem like they'd be affected at all during the grace period where this is worked out.

This is precisely why corporations don't jump on new OS releases the day they come out. There are always things that will need to be found. It's not really the OS makers' job to ensure compatibility with all software installs available but they should do a reasonable job at documenting any changes and collecting error reports so 3rd parties can issues patches and become compatible. In this case it sounds like Chris is doing a lot to ensure compatibility with a wide variety of modules but as the ecosystem grows it's going to be harder and harder for them to do this - which is why I think it's great there is a community offering support and even Secret Labs resources to help work this out.

Bottom line - yes, it might be an annoyance to users but that's all it is. It's growing pains. On the upside it's not a hardware change - it's just a software release that will likely need to be undertaken. Again, this is not unexpected in a pure software world, mixing it with hardware doesn't exempt us from this situation.

I think this is a good point to thank theTroll for the bug report and close the thread. Further discussions of how to resolve this particular issue would be better suited on a builders board, not the community board. Any resolution from that discussion, if it seems applicable to other module builders, should of course be shared. There is nothing to hide but to many this is just noise and if they found this thread because they hit the problem, they had their answer many, many replies ago.

-Erik