The Infuriating C# Out-of-Code References
I love C#. It takes everything I loved about my years programming in early Java and adds boatloads of wonderful. But, there is one thing that perpetually infuriates me. All C# source code includes coder-included class, type, and other references that are all relative to a list of "using" statements at the top of the source code file and also a list of libraries managed separately in the Visual Studio UI. The problem is that all the wonderfully helpful source code that people post on the web never includes these UI-managed library references, which means that any time you copy and paste those bits of C# source code you will get lots of squiggly red lines telling you that Visual Studio has no idea to what the classes, types, etc. given in the source code refer. And since I've just searched the web because I didn't know how to solve a problem or because I'm learning some new framework or paradigm via some example on a page, I usually have no idea what library or libraries I need to reference in order for all the dependencies to be satisfied.
Case in point, I just had a look at the Google Drive API "Quickstart". They show you a simple snippet of source code you are supposed to try yourself. They do not give you a Visual Studio project, just the code on the screen you need to copy and paste. They also tell you to download the API libraries. I did. The library has what looks like a common library directory with 10 or so DLLs (and various other files) and a separate folder with 45 folders for various "Services" and inside those more DLLs. And I am somehow supposed to know which DLLs this 20 line piece of source code needs??? So to be safe I end up including all the common libraries and both the libraries under the "DriveService". But the code won't compile. All the references are satisfied but now there's ambiguity between because an extension method is defined in two separate imported DLLs. It takes me another 20 minutes to figure out which one I don't need. Why do we have to go through all this??? It is all so utterly needless. I can't tell you how many times I've been unable to try out a piece of source code because something has gone wrong in figuring out and finding the libraries that were needed, and which versions of the libraries were needed (since libraries can radically change with every release).
What boggles the mind is that neither Visual Studio nor third-party VS plugins like ReSharper do anything to help. Surely something could be done to largely eliminate this problem! At the vary least, why couldn't they include a "header" like region at the top of the VS editor UI which lists the actual fulfilled references for that active file. It wouldn't actually be part of the source code, it would just be a handy little (perhaps collapsed) virtual piece of commented code that would be copied whenever you ctrl+a ctrl+c file contents. And when you pasted it elsewhere it would let people know what out-of-band files they were missing. The format would probably just specify the Portable Executable data for the file and the hash (not the actual path which would be less useful and less anonymous).
Here's hoping they do it one day, or someone makes a nice little third-party plugin that is able to sort it out for you (by having a massive DB of exported library functions and some good heuristics)...
^ Q
Copyright protected by Digiprove © 2013 Quinxy von Besiex
Google+ Hangout C# Control / WPF
The free, multi-party video conferencing offering Google+ Hangout is a pretty fantastic alternative to Skype (and its paid multi-party option). Wouldn't it be wonderful to have a UI control you could drop into any .NET application that gave you all the power of Google+ Hangout? Well, it would... and I've been working on it, but so far it's not proved easy.
First a bit of back story. I have been working on an app which features embedded video conferencing and had gone initially with Skype. Skype has been a somewhat miserable experience thus far, workable but only just. The only way I've been able to integrate with Skype thus far has been their Skype4COM option. Skype4COM allows you to remote control certain features of Skype from a third-party application. You can initiate calls, hangup, mute, and things but you can't hide the original Skype interface or embed its video in your own application. There is a way to do all that, and it's SkypeKit. But for reasons unknown to me they seem to have suspended SkypeKit access. I applied to the program many months ago and my account still says something like, "We'll get back to you about SkypeKit when we're ready for you." I've heard from others that that's just the way it is right now, that they are redoing SkypeKit or something. At any rate... Skype isn't a great solution at the moment. Google+ Hangout on the other hand would be perfect, if only it worked.
I spent a few days a few weeks ago trying to create a Windows control that would let me embed Google+ Hangout inside a Windows control. The logical approach to do that would be to customize a web browser control to load up the web-based Google+ Hangout and just modify the rendered content and inject JS as necessary to achieve the desired control-ifying of Hangout. I've done that before, so I didn't think it would prove so tricky.
Microsoft WebBrowser Control
I first tried using the built-in Microsoft WebBrowser control as the hosting control. I automated Google account sign-in and had it load up the Google+ Hangout page. I hit the first major roadblock. The page gave me a warning about my browser agent not being supported. I went back and added code to spoof it, but that didn't seem to work as the WebBrowser control isn't all that sophisticated and only spoofs the user agent for the first request, not subsequent ones or ones that the loaded page fetches. I tried several alternative WebBrowser extension classes that try to intercept navigating requests and replace them with navigate calls that include the spoofing, but they didn't seem to work properly. If memory serves I did reach a point where I was able to call the JS to start a hangout but everything hung when it tried to install/start the hangout.
Awesomium
The next option I tried was Awesomium, a Chromium-based behind the scenes browser rendering system. After looking at some of their examples and struggling a bit with their concept (which differed radically from the WebBrowser control and MozNET control approaches I was used to) I ended up realizing I could use one of their demo apps as a quick way to test the concept. They had a tabbed web browser demo which I used to access Hangout. I was able to initiate a Hangout but the video of the Hangout was not contained as it should have been within the Awesomium demo browser, the Hangout window was at the top left of the screen whereas the browser was in the middle. So it worked but if they couldn't control where it was rendering then I didn't think an Awesomium would be an easy solution.
MozNET / Xulrunner
Next I tried my old friend, MozNET. MozNET is a XULrunner implementation which I've quite enjoyed using before. There again I wen the easy route first and used a demo browser example to see if I could get it working. Sadly it did not work. It would just hang at the step where Hangout is checking for its plugin. I feel like a MozNET solution wouldn't be too hard to achieve, but I don't have the depth of knowledge in it to make it happen easily. I know MozNET can be made to work with various XPI-based plugins.
Oddly enough, Google+ Hangout doesn't seem to be an XPI plugin. I did a procmon.exe dump of a Firefox when using Hangout and I see access to:
C:\Users\foo\AppData\Roaming\Mozilla\Plugins\npgoogletalk.dll
And a separate EXE gets launched:
C:\Users\foo\AppData\Local\Google\Google Talk Plugin\googletalkplugin.exe
But I'm not sure how what is doing the communication between Firefox and the Hangout code.
If anyone has any thoughts they'd like to share, please let me know! I think the world would benefit from an embeddable Google+ Hangout control... I know I would.
^ Q
Copyright protected by Digiprove © 2013 Quinxy von Besiex
.Net (dotnet) Install Base Statistics – Picking Your Framework Version
When building C# applications in Microsoft's Visual Studio 2011 you must make a choice, which .Net framework do you target? As a developer we'd all love to target the latest framework which has all the latest features, but you don't want to lose out on a huge percentage of potential users who balk at the torturous Microsoft .Net installation. If a user doesn't have the needed version of the .Net framework they'll be forced to download an additional 25+ MB file, forced to wait as that framework is installed, then forced to close all their applications and reboot their computer. With past applications we've deployed we've seen as many as 30% of people abandon our software's installation in order to avoid the .Net installation. Picking your framework is, therefore, important. Target the wrong one and you'll lose more users than you need.
It has been difficult to determine just want version to target as Microsoft hardly wants to publish the anemic numbers themselves, and no one else seems much interested in sharing their own. We included a .Net version checker in some of the software we distribute to find the truth ourselves... and here it is. These numbers represent the users coming to DriverGuide.com, so other sites with different audiences would likely see different numbers, but I suspect they'd not be too far off.
| .Net Version | Percentage of Computers Scanned |
| pre 1.1 (or none) | 21.6% |
| 1.1 no service pack | 27.2% |
| 1.1 SP 1 | 24.6% |
| 2.0 no service pack | 74.2% |
| 2.0 SP 1 | 1.7% |
| 2.0 SP 2 | 62.7% |
| 3.0 no service pack | 62.4% |
| 3.0 SP 1 | 1.0% |
| 3.0 SP 2 | 61.5% |
| 3.5 no service pack | 61.6% |
| 3.5 SP 1 | 61.3% |
| 4.0 client install | 28.3% |
| 4.0 full install | 5.6% |
Unless you can be sure your users will tolerate the painful .Net framework installations this data clearly shows you only have two real choices, either target 2.0 and seriously inconvenience 25% of people or choose 3.5 and seriously inconvenience 38%. Neither are good options, but they are what Microsoft leaves you with.
One alternative which we've flirted with in the past is to bypass the horrific .Net installation requirement was using Xenocode's Postbuild software to create a distributable that was free of the .Net installation because the exe built with Postbuild included the necessary .Net components inside a virtual machine wrapper. It worked beautifully, but made our tiny 150 KB executable into a self-compressed 25 MB executable. Still, in this day and age of broadband Internet one could hardly argue it wasn't a far better user experience. Xenocode Postbuild has since morphed into a more encompassing idea with a slightly different built utility called Spoon Studio which we are currently testing; we've found similar results so far.
Virtualization was done with Spoon Studio and bundled the .Net 3.5 Client Profile.
| Compression Method | Size |
| Raw, Spoon Not Used | 150 KB |
| Streamable / No Compression | 50 MB |
| Not-Streamable / Compressed by Spoon | 18 MB |
| Not-Streamable / Compressed as RAR SFX | 15 MB |
| Not-Streamable / Compressed as 7-Zip SFX | 13.5 MB |
We will likely do what we've done before and deploy a tiny installer which bundles only in only the raw .Net dependent executable and then for the 40% of people we see don't have the right .Net version we'll automatically fetch the larger monolithic exe they'll need over the net. It's as near to an ideal situation as we can have when Microsoft insists on making .Net installation so horrible.
^Quinxy