Like most .net devs, I fell in love the the web.config transforms that were introduced in VS 2010. And like most .net devs, I miss having them for other types of files, say, like App.configs. There is the SlowCheetah VSIX, but this imposes yet-another-build-environment-dependency on the downstream consumers of your source code. Since I’m working on a project that will ultimately be released as open source, that strikes me as one more barrier to participation, and one more thing to make automated deployment a pain. So here’s how I went about implementing it.
My colleague Paul Irwin just posted an article called Translating Objective-C to C# – Part 1 of n. I think it’s an excellent synopsis. Having myself spent nearly a year and a half doing Objective-C programming part time before learning to C#, this is a topic that hits home for me. There are a couple of areas that warrant some additional clarification, as they are obscure for most Objective-C and .NET programmers alike.
If you have, or have access to, a workstation with an x64 version of Visual Studio, you can configure Azure diagnostics to collect and copy the crash dumps to Blob Storage:
// Must be called after diagnostic monitor starts. CrashDumps.EnableCollection(false);`
You can then download them (using a tool like Azure Storage Explorer) and debug them locally.
If you are planning on doing any appreciable amount of work developing Azure applications using Visual Studio, and are still running x86, you should consider migrating to x64 Visual Studio sooner rather than later. This is even more the case if your application relies directly, or indirectly, on unmanaged code.
The potential performance pitfalls of DateTime.Parse are well discussed. What I don’t see as often: actual performance test data.
So, I’m contributing my own test data to the discussion. Read more…