Qt5Package Extension and Win32/x64 Configurations in VS 2015

I may be using this awesome Visual Studio 2015 extension incorrectly; however, whenever I import a Qt Creator PRO file into Visual Studio using it, I get the default Qt configuration which is my x64 config.

When I go to add a Win32 Configuration, I get errors about how "There's no Qt version assigned" and it instructs me to change the Qt version.  The problem with that, is that when I try to do this via the Qt properties on the project the extension tells me "Value cannot be null. Parameter name: qtVersion."

I beat my head against the wall a bit trying to fix this and none of the online suggestions solved my problems until I found a 'several pages in' post saying to do the following:

Open your newly created project's .vcxproj file in a text editor, scroll down (usually near the very bottom) until you find some user properties for the extension.

In my project they were found in the section (this screenshot shows the location as well as the fix):

(Click on image to expand)

In my project file, before I edited the UserProperties element, there was no name/value pair for Qt5Version_x0020_Win32 - the entry only had the value for x64.

Knowing that I had configured the extension with a Win32 version with the name "Qt 5.6 x86" I added the missing name/value pair, saved the project file, re-opened it in Visual Studio and was successfully able to build.

The string YOU use for the value of Qt5Version_x0020_Win32  or Qt5Version_x0020_x64 will be dependent upon how you have configured your extension.  For example, if you have not yet defined a Qt version that points to an x86/Win32 version of Qt - you won't be able to reference it from the project file.

You may have the reverse of my problem in that your default Qt installation referenced by the extension is the x86/Win32 version of Qt.  In that case, you'll be missing the other value (which I already had.)  Just use the same process and you should be fine.

Hope this helps!

Building Qt 5.5 minibrowser sample application

For the life of me I couldn't understand how a basic sample application in Qt could fail to run, everything else was great - just not the minibrowser sample.

I was getting the error -

Starting C:\Qt\Examples\QtWebView\1.1\webview\build-minibrowser-Desktop_Qt_5_5_1_MSVC2010_32bit-Release\release\minibrowser.exe...
QQmlApplicationEngine failed to load component

qrc:/main.qml:44 module "QtWebView" is not installed

- when running the built sample.

After much grumbling and searching (I didn't find anything helpful on the inter-tubes which was really surprising) - I found that the main.qml file was referencing the following:

import QtWebView 1.0

I found that if I changed this to:

import QtWebKit 3.0

It would run properly (I presume.)

This may be sidestepping the actual issue, but this appears to have fixed this sample for me.

This version was the one I found in the plugins.qmltypes in the qml import path.  Perhaps I had not configured an import path properly when installing Qt - it's possible this is entirely my fault; however, if it is not, hopefully this will help someone.

Repairing .NET 4.0 in Visual Studio 2010

I recently had problems installing security patches to the .NET 4.0 runtime, you know, the kind of problems that give you an absolutely generic installer error that leads absolutely nowhere.

Anyhow, I tried uninstalling .NET 4.5 and 4.0 completely and re-installing them - great, all fixed except for one problem - Visual Studio 2010 could no longer target .NET 4.0 (much less .NET 4.5+.)

Repairing Visual Studio didn't fix it, a whole slew of inane ideas and attempts didn't fix it - ultimately I found a guy who had a way that DID work for me that was short of uninstalling and installing Visual Studio again.

Just install the "Windows Phone Developer Tools" from 2010 (Web Installer.)  Running it will download all of the components and then it will begin installing, the second thing it installs is the .NET 4.0 multi-targeting pack.  As soon as that second item finishes installing just cancel the install - it won't roll you back.

Presto!  Visual Studio now recognizes .NET 4.0.

Thank you Xander Hyde wherever you are! -> http://tinyurl.com/qhtok24

Mono / Unity3D C# HTTPS HttpWebRequest Asynchronous craziness

Beware, ye crabby developers, of using HttpWebRequest asynchronously with SSL connection because there appears to be some crazy bug that causes a timeout (defaults to 100 seconds if I recall correctly) that yields a null response.

I spent the entire morning (and I ran into this previously on iOS a year ago and put it aside for a day when I felt like bashing my head against rocks) wondering why some simple asynchronous download management code I'd written work wonderfully for FTP and HTTP but then nothing seemed to happen when using a URL with HTTPS as the protocol...

I did the usual things like ASSumed it was a self-signed cert issue so I overwrote the certificate acceptance code - no luck.  I spent a bunch of time trying to understand the error messages I was catching on exception, ultimately tracing it down to a timeout on the OTHER end of the connection yielding a "connection forcibly closed" which told me that my server was actually saying "look meathead, if you're just going to sit on the line I'm going to cut you off so I can help someone else..."

So, I started Googling.  An hour later after reading about a ton of other people having this issue (but nothing mentioning 'debug') I caught a little bugzilla entry mentioning 'odd behavior' with HttpWebRequest when running in DEBUG.  So, having exhausted all rational attempts to resolve the issue I said "screw it, let's see if it works in release, guffaw, chortle..."

Bang, 8 simultaneous HTTPS downloads worked like a charm.

Un-FREAKING-believable.

So, if you too have crazy HTTPS issues that defy reason and you're using Mono/Xamarin/Unity3D, give your friendly neighborhood release mode build a try and see if it magically solves your ills.  I know mine did.

Hey Mav, do you still have the number of that truck driving school?  Truck Masters I think it was called...

WordPress Multiple Install IIS URL Rewriting Problems

Okay...  This has given me a gigantic headache (both figuratively and literally) all morning and thank goodness I've finally managed to hack a solution to it...  Technically it isn't a hack, but it sure smells like one.

We have an unusual situation where sales & marketing has its own WordPress installation at the root of our website and the support group has its own separate installation under /support.

The web server that we're currently using is an IIS 7 server, which means that WordPress is operating with no .htaccess files and using web.config.  Each base directory has a web.config.  Each WordPress is using its own Database and has its own database user.

So...  Problems arose when enabling permalinks (pretty ones) for the support site.  I couldn't figure out why going to any of the site pages was yielding a 404 error (emitted by WordPress' PHP.)

My hosting provider couldn't figure it out either - which really got me worried, so after slogging around endlessly, and reading about all the other people using multiple installs and having minor configuration issues, I really started to pull my hair out lol...  I then ran across an obscure post about a guy mentioning WordPress and ASP.NET configuration inheritance issues.  This led me to other posts about nested ASP.NET applications issues, which ultimately led me to the following magic:

<location path="." inheritInChildApplications="false">

Thanks to the wonderful person found at:

http://articles.runtings.co.uk/2010/04/solved-breaking-parent-webconfig.html

Basically, IF you have a WordPress installation in a sub-directory of your website that is hieararchically a child of another WordPress installation, and you're on an IIS web server, you need to edit the root WordPress installation's web.config file and surround it with the location element.

After doing that, my permalinks started working again just fine.  (Thank G-d...)

Visual Studio 2010 Web Publish over FTP

It seems like you can't use TLS or SSL to protect your FTP data when publishing from Visual Studio, but I just found out that you can.

There's no direct "FTPS" publishing mode, you simply select "FTP" and then make sure you use the correct protocol in the URL (i.e. "ftps://ftp.mysite.com/somefolder")

Many people probably knew that but I didn't...