Build Error

The next hurdle in the installation and “bring up” of a refreshed NETMF development environment…The facts…

  • VS2012 PRO
  • Removed GHI SDK 2014 R4, MS .NET Gadgeteer SDK (blah, blah .900), NETMF 4.3 QFE1 (in that order)
  • Installed NETMF 4.3 QFE2, MS .NET Gadgeteer SDK (latest ref’d on GHI instructions), GHI SDK 2015 R1/PR
  • Updated G120 module TinyBooter and firmware without issue via FEZ Config

Now on build attempts, I get the following charming issue…

[No MetadataProcessor tool found at “C:\Users\GEB\AppData\Local\Microsoft\VisualStudio\11.0\Extensions\xmxgbqbd.2ws\MetaDataProcessor.exe” C:\Program Files (x86)\MSBuild\Microsoft.NET Micro Framework\v4.3\Device.targets]

I’m reporting this with the good of the realm in my mind, but also in the hopes that a silver bullet is available…If I develop a workaround, I’ll post it here…

Let me (us, really) know what you think…

GEB@ SIM

Workaround is here : http://netmf.codeplex.com/workitem/221

I can’t speak to the correctness of the rest of your setup, but this fixed the issue for me many moons ago.

@ SIM - Any reason fro not using VS2013? It is where we are it today as far as current support.

mcalsyn & Gus

Thanx much for the quick response…I’ll work with the specified tech note and get 'er going…

With respect to VS2013, I like to keep change to a minimum where possible, and frankly I tire of new and arbitrary twists of well-established VS functionalities that must be changed for, apparently, change’s sake – ref 2010 to 2012 changes a-plenty: search dialog nonsense, “halfway” appearance of files on element lookup request (ooooh, purple!), removal of macros (what the hell)…etc…etc…etc…they waste our time with this feature “churn” and I’m getting too dang old to warm to the shiny makework-of-change stuff…anyhoo, perhaps I’m a Luddite…

Had been cooking along on GHI NETMF SDK 2014 R4 for some time (and would still be…grin) but was strongly drawn to native implementations of .Bitmap conversion functions…

  [b]"Fixed Bitmaps.Convert and Bitmaps.ConvertToFile corrupting the data."[/b]

…as I’m wrapping up a video capture API based around the USB camera (yeah, yeah, ALCAM…actually quite looking forward to it, but we must walk before we run)

BTW, with respect to this week, change is welcome…ALCAM, S80, G120E…very, VERY nice stuff…

GEB@ SIM

Gentlemen…

Turns out that mcalsyn was in the vicinity, but the specified workaround wasn’t the solution…

[quote]Workaround is here : http://netmf.codeplex.com/workitem/221

I can’t speak to the correctness of the rest of your setup, but this fixed the issue for me many moons ago.
[/quote]

…but it got me to reexamine the scenario, so bravo!

Turns out that MetaDataProcessor.EXE isn’t misbehaving but instead really WASN’T WHERE IT WAS EXPECTED. I didn’t give the error message enough credit for being precise (go figure, I’m a trained MS seal – nothing is generally as it seems). The file, normally executed from “{NETMF 4.3 Install Directory}Microsoft.NET Micro Framework SDK v4.3\v4.3\Tools” was referenced instead in the GHI 2015 R1/PR Visual Studio extension folder “C:\Users{login acct ID}\AppData\Local\Microsoft\VisualStudio\11.0\Extensions\xmxgbqbd.2ws” (or similar)…

Looked around pretty carefully but could not find a direct, or even indirect, reference to this folder, strongly suggesting that the path was derived at runtime…Tried a shortcut into the NETMF Tools folder – no dice…it wants the real deal.

The key files in the VS extension folder, though packaged with a different date, match corresponding ones in the NETMF Tools folder byte for byte…So I backed up the original extension folder contents and then copied all of the files from the Tools folder to the VS extension folder…BA DA BING, BA DA BOOM, full build, deployment, and run-on-SoM success…

This is far from a favorite solution as referencing the true and intended file locations are what the original system design called for, but with MSBuild, it’s generally best to yield in the face of overwhelming complexity and provide the warm, loving environment that it expects…

GEB@ SIM

[quote=“SIM”]
With respect to VS2013, I like to keep change to a minimum where possible, and frankly I tire of new and arbitrary twists of well-established VS functionalities that must be changed for, apparently, change’s sake[/quote]

I still use Visual Studio 6.0 for some things, lol.

I am glad to see I am not the only one that thought removing macros was a horrible idea. I am no VS power user, but the macro feature I used.

RE: Visual Studio 2012 Macros…

You’re probably already aware of the “Visual Commander” option to transition macros into Microsoft’s macro-free world OR learned to live without, but in case not, take a look…

https://vlasovstudio.com/visual-commander/index.html

…had to munge my existing macros some to get them to behave, but not too, too much…a good solution…

RE: Visual Studio 6.0…

Sometimes the old ways are the best ones – practical magic…the young don’t have BETTER answers to the same old questions, just DIFFERENT ones (from time to time my inner cynic needs and airing…done)

GEB@ SIM

I’m still waiting for embedded COBOL

I respect persistence. :whistle: