I like the Idea of IoT... I just hate screwing around with junky raspberry pi boards... why can't Microsoft help people by have their "Microsoft Mouse" people create a cheapo "LoT native kit", its simply a USB cable that plugs into a card with 40 pin header with periphicals that exactly match what's available on a "raspbery pi", "minnow board", or Qualcom 401c dragonboard. Except you can nativelly run your code from your Windows 10 PC... if I had that, i wouldn't even bother buying raspberry pi boards, etc... I would probably find the cheapest Windows 10 Tablet from a chinese manufacture for $80 and plug the "Native LoT kit" into the USB port instead to get GPIO, I2C, and the IoT buses for talking with senors etc... when I want to go cheap, then I can just depoly to a $28 raspberry pi without needing to ***** around with junky hardware well developing....

I just don't understand why microsoft doesnt' supprot that... if they already support raspberry pi anyways... it cheap and easy as heck to create a USB adapter that matches the GPIO of a raspberry pi with GPIO/SPI/I2C/UART etc... microsoft could even hide that they had anything to do with it.... just seed some chinese companies to do the work for them and make sure they work with Windows.Devices.GPIO, etc... etc... and that they have a raspberry pi, minnow, qualcomm 410c compatibility mode. with the header they provide....

better yet, ,microsofot can provide a way for people to register a device ID onto the loT native kit so that they are "plug and play"... you IoT soft just request the DeviceID matching the GPIO/SPI/IC2/etc.. header dongle... solving the problem with enumerating devices that serial port have anway had in the past... i don't care... if they are hardwires on to a secondary hardware board to hardwire circtui boards there;'s no way they will ever get mixed up other than verifiy the vendor and product id of that was burned in to the "IoT development kit dongle" for native windows IoT devices...

Seems to me...the XAML development people should stop ******* their heads on the wall and directly steal some of the HTML ways....

Like why does UWP not have a spreadsheet control??? Seriously, I'm thinking about inserting a WebView control and writing HTML!! just to get a spreadsheet inside of UWP application... this is not only messy, its ashamed thast XAML has no way to do this natively... Should we just all toss in the bag and write javascript instead....as much as I hate hackish script laugages like javascript over C# ... it seems the HTML controls are better!!!! over non-existent for UWP/XAML///

I am working on a C# unit test libary. I often start a test debugging and editing. From time to time I make edits that make it impossible to continue without recompiling.
So the well-known dialog is displayed:
Edit and Continue: Edits were made to the code which cannot be applied while debugging. Click Restart to stop debugging, rebuild the code, and restart debugging. Click Edit to make changes to the code.

The problem is, clicking Restart really is not an option. The dialog after that gives the reason:
A project with an Output Type of Class Library cannot be started directly. In order to debug this project, add an executable project to this solution which references the library project. Set the executable project as the startup project.

Well, even if there was an executable in the solution, it would not be the correct way to take me debugging back to were I was.
Please reduce the number of dialogs to get me debugging the unit test and remove the unreasonable suggestion.

When programming languages began they where structured well enough to deal with the complexities of applications at the time. Then as apps got more sophisticated the existing languages became overwhelmed by the complexity. Thus assembly language programming changed to C which changed to C++ and now to C#. Each of these steps "cleaned up" the mess layered on top of the prior language to help it deal with more sophisticated apps.

XAML has been great, but it's been taking on more and more burden. In response, an improved ability to structure XAML better is needed. Ways to break down huge XAML files into smaller, likely reusable, components.

With the introduction of more and more "fancy" to XAML (animation, depth, etc), being able to break down an ever-increasing size XAML page file into more manageable sub-files is becoming increasingly critical. The next step is introducing "XAML macro" files where the reference to a XAML macro file can include parameters that get substituted into the merged XAML as the referenced file is merged at compiler time.

For some reason in my instance of the IDE and project, VS takes a good 30seconds to a minute after the tests are complete or after it tells me there was a compile error before it will let me run the tests again. And during this time, Ctrl-r, Ctrl-t is unavailable.

It would be much nicer if run tests command was still available and if it can't run the tests immediately, it puts the command on a queue that will get run as soon as whatever is happening finishes. (I have no idea what VS is doing for 30 s to 1min after the tests are finished).

Without this capability, I sit there hitting Ctrl-r,Ctrl-t listening to that stupid ding sound until the background task is finally finished and it kicks off the tests. I probably hit the key combination 20 times before it takes it. I should only have to hit it once.

Here is a typical workflow:
I make some changes that breaks compilation in a derived class I don't have open, so I didn't notice the compile error. I run the unit tests on the class I am working on. As it is compiling, I see the error and fix it while the compiler is still compiling because it takes a minute or two.Then the system comes back with the dialog that says - there were build errors do you want to run a previous version. I say no.

This is where VS goes off and does something for 30 seconds to a minute (most times, but not all times) and i am stuck hitting ctrl-r,ctrl-t repeatedly until it finally decides to listen to what I want it to do.