I really like development in Visual Studio even if I have a feature to implement for other platforms. And anytime I can I try to continue this experience. Period.
This time I had a pleasure to wrap several HTTPS calls using libcurl. But how to make it run on my x64 Windows machine? There is some info on StackOverflow.com, what can be moved to VS2017 in following steps:
- Start VS2017 console: "%ProgramFiles(x86)%\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" amd64
- Download the curl-7.53.1.zip source-code and unzip it
- enter “winbuild” folder
- compile with Windows SSL build-in support: nmake /f Makefile.vc mode=static VC=14 ENABLE_IPV6=no MACHINE=AMD64(optionally mode can be set as ‘dll’ to have later one more DLL do deal with in the project)
- grab the outcomes from “/builds/libcurl-vc14-AMD64-release-static-sspi-winssl” folder
- setup new project’s ‘include’ and ‘lib’ folder (put libcurl_a.lib or libcurl.lib into references)
- and remember to take a look at samples!
Lastly I have shown how to enforce encoding of strings in DBF table by setting up code-page inside its header. I also mentioned it was the easiest way. That’s still true. But sometimes there is no room to be polite and things need to be done little messy in the code (for example when the DBF file is often recreated by 3rd-party tool an can be altered in any way). So each time the string value is loaded try to recover it with those steps.
First get the original bytes stored from loaded *text* (assume that system inappropriately returned Windows-1250 encoded string):
var bytes = Encoding.GetEncoding("Windows-1250").GetBytes(text);
Secondly convert them from correct encoding (it was natively stored as Latin-2 aka CP-852) to UTF-8:
var convertedBytes = Encoding.Convert(Encoding.GetEncoding(852), Encoding.UTF8, bytes);
Of course encoding objects can be cached to increase performance.
In my recent post I have shown, how to track web requests issued against remote server I don’t have a control over. Curious reader could ask at this point – but what have I broken this time? And the answer is as usual – personally did nothing wrong, I was just doing my job. I had to port some HTTP related code from using Windows Runtime-specific HttpClient (i.e. Windows.Web.Http.HttpClient) to also work outside the sandbox on a regular .NET 4.5 desktop version and start using System.Net.Http.HttpClient instead.
Then I noticed that everything worked fine except multipart form-data submissions using POST method that were behaving unexpectedly bad (timeouting or returning an error immediately). There was nothing unusual mentioned on MSDN, so I started to compare sent requests using both implementation. It turned-out of course, the problem lied deeper in the framework in a value serialized as a *boundary* part of the Content-Type field. HttpClient from the System.Net.Http somehow was adding extra quotes around it, while the one from Windows.Web.Http didn’t. Even though server should accept both values (according to RFC2046 section 5.1.1), it actually didn’t and was waiting for correct *boundary*.
Simple fix by manually overwriting the guilty header can look like that:
var request = new HttpRequestMessage(HttpMethod.Post, url);
var boundary = "--" + Guid.NewGuid().ToString("D");
request.Content = new MultipartFormDataContent(boundary);
// fill content
// update the Content-Type header to be accepted by the server:
request.Content.Headers.TryAddWithoutValidation("Content-Type", "multipart/form-data; boundary=" + boundary);
// send request:
var result = await _client.SendAsync(request, HttpCompletionOption.ResponseHeadersRead, token);
World saved. Job done!
Usually it’s not a big deal, when a HTTP request to a remote server is not working on a desktop Windows machine. There are plenty of useful tools, that could help in the process:
- one, which work like a proxy and dump the whole traffic, that we might be interested in (Fiddler would be the best example here)
- others, that interact with the TCP/IP stack itself and look much deeper for sent packets (like WireShark or Microsoft Message Analyzer).
BTW. Do you know, that there is a way to visualize HTTP traffic in Fiddler, that was originally captured by Wireshark or MMA?
Simply export packets from WireShark as pcap file (File –> Export –> Export as .pcap file) and import it directly into Fiddler (File –> Import Session… –> Packet Capture).
Many thanks to Rick Stahl, for showing me this feature.
Mobiles are totally different world. Mostly because applications are running in a dedicated sandbox and there isn’t at all internal or external access on system level. There is not much to do beside debugging of our own code. But if this doesn’t help, it doesn’t mean we stay blind. Take a look at http://httpbin.org/ (project sources available on GitHub). It’s the server you always wanted to write yourself – server that returns info about client accompanied by a list of headers, info about content for all kinds of submitted requests and even some random binary data, if you like. Respective behavior is selected by dedicated path on the httbin.org server and response is of course in JSON format (maybe beside for the binary data request).
Typically request paths:
- /delete – all of them to know, how the request really looks like
- /status/<code> – to verify, if the application handles given error respectively
- /stream-bytes/<size> – both to download some random binary block of bytes from server.
It *won’t* simulate your destination server at all nor any more advanced interactions. And you will need to to hack your application to be able to issue requests against this server and dump somewhere the JSON response. Still remember, it’s only during application development and while fighting with a non-working request against remote server you totally have no control over, so additional #ifdef won’t hurt at all ;)
Final thought – the trick described above could be also without any problem used inside desktop or Windows Store application. It’s not only dedicated to mobiles!
With the recent announcement of Visual Studio 2015 RC you, as a developer, are now able to write applications targeting iOS, Android and of course all kinds of Windows platforms, web and cloud. I am also pretty solid, you will be happy to hear, you can make your applications run on BlackBerry devices (including PlayBook!) as well. I just recently updated integration of the BlackBerry Native Development plugin with latest version of Visual Studio, so you can stick to your favorite IDE and continue coding without lowering your productivity. Grab it directly from Visual Studio Gallery, to be always up-to-date, when new releases are published in the future.
Notice that this plugin supports wide range of Visual Studio versions, from 2010 till the most recent ones now.
The current state includes features like:
- dedicated "New Project" and "New Project Item"
- automatic MSBuild update (without any manual plumbing) on new version releases
- GDB integration
- IntelliSense support
- Qt 4.8.3 for PlayBook support via dedicated set of NuGet packages
- QML basic colorizing support
- device browsing support
- dedicated settings to tune all aspects of project build and deployment
- support for C++0x and C++11 features (limited to OpenGL applications)
- and much more!
This package provides Native SDK, Qt and Cascades support inside Visual Studio for PlayBook and BlackBerry 10 devices. It encapsulates whole development cycle - from developer registration, via coding, deployment, debugging, until the final release to AppWorld marketplace.
There are for sure some bugs or things you could wish to be improved. So don’t hesitate and let me know about it. You can always contact me directly, twitter @CodeTitans or submit a feature request on project’s website. Please only take into account, this project is **not** sponsored by any company (BlackBerry nor Microsoft in particular) and I do it only in my spare time, when not working for food!