Back to Blog index.
Great news: a new preview version of Windows 8 has just hit the cloud, so to speak: you can download what is called the "Windows 8 Consumer Preview" from many locations, including MSDN Subscriber Downloads, Technet, or public sites.
The latest developer info can be found on the Apps developer portal. I'm pretty excited on the new Metro opportunities, it's one of the biggest changes in Windows development since .NET was introduced.
PS. In Finnish, there's a new web page available for general info.
From time to time, I find myself writing some Win32 API stuff with C++, last time related to Volume Shadow Copy (VSS) backups late last year. For me, C++ has always been the language with which tough system-level problems can be solved, but nowadays I don't need the language that often, as languages like C# provide enough power for most needs.
Even so, if you are like me, every time you need to get something more complex with C++, you need to remind yourself of the syntax and tricks. For that matter, I've recently found a nice document describing the differences between C# and C++, with the presumption that the reader is already familiar with C#.
If you need to learn or use C++ but are familiar with C#, then this is recommended reading.
Quick link share for today: if you are looking forward to develop Windows 8 applications where touch is first and foremost, then this new touch guidance document from Microsoft should be well worth your time.
Happy developing!
I've recently been working with mobile-optimized web applications, and chose to test ASP.NET MVC 4 preview/beta for a particular project I've been working on.
ASP.NET MVC 4 contains a mobile-optimized rendering template that works pretty well on all the major mobile platforms I've tested it with: Android, iPhone and Windows Phone. All in all, there isn't much manual tinkering that you need to do to get things working, and I expect things to get even smoother as Microsoft prepares the MVC 4 release to go gold.
A beta version of the MVC 4 framework has just been published, you can download your copy here. The earlier Developer Preview was made available in September, 2011.
Just a gentle reminder: if you are interested in Microsoft's technologies and future products, the next TechDays 2012 event to be held on March 8–9 at the Helsinki Fair Center "Messukeskus" is here soon. I'm speaking at the event in three sessions, two on my own and a third one with a colleague in the field.
As there will be more than 2,000 attendees this time, be sure to select your preliminary schedule when you register. This allows local Microsoft people to find a suitable room/hall for each of the sessions.
See you there!
I find myself pretty often in a situation where I need to split a C# string into lines that are delimited with the regular Windows carriage return (CR) and line feed pairs, CRLF in ASCII parlance.
Well, the C# string class contains the Split method, but I always wonder why the parameter overloads do not allow you to give a single string parameter. Thus, I'm sharing my code snippet that I'm pretty often using in a situation like this.
Here goes:
internal static string[] SplitToLines(this string input)
{
return input.Split(new string[] { "\r\n" },
StringSplitOptions.RemoveEmptyEntries);
}
Happy hacking!
If you are using the latest version of ASP.NET MVC, it is pretty likely you've also started using the Razor view engine. Since everybody is comparatively new to Razor in production systems, I thought I'd share a simple tip on how to output static text from within Razor view pages, for the the .CSHTML files.
In Razor, a code block starts with the @ sign, and in the C# version, you can also write complete code blocks with the @{ } construct. But if you use such a multi-line code construct, how do you output static text within it?
Of course, you could use the canonical Response.Write method, but that's a bit tacky in otherwise very smooth Razor view pages. A better alternative is the @: construct, which indicates to Razor that the next symbol will be static text, and will be outputted as is (with html encoding).
If you instead want to output bigger amounts of text, such as a few sentences or even multiple lines, you can use the <text> tag. Whenever the Razor engine parses the code and finds a <text> tag, it takes everything between and the starting and ending tag and outputs them as literal text.
For the past couple of years, my choice of database access technology in many different types of .NET applications has been Entity Framework. No, I'm not saying Entity Framework is the only option, nor is it always the best solution, but oftentimes, it's a convenient and useful technology that can save you a lot of development time.
Now, in all automatically working wrapper classes (which Entity Framework more or less is from 10,000 feet) performance is a question. I've been happy with Entity Framework's performance, but then again, the way you write your code will have a big impact on the performance you see.
If you are looking into improving your data access performance and you are using Entity Framework, be sure to step by the topic titled "Performance Considerations" on MSDN.
For a week or so, there's been quite a lot of speculation on the Internet about Windows Phone's next big version, codenamed "Apollo". For instance, PocketNow contains an article about Apollo.
What's interesting for developers is that supposedly, the next kernel in Windows Phone 8 will share quite a lot from the ARM based kernel of the desktop/table operating system Windows 8. This, if true, would actually be a very important step in assuring that the same codebase can function on both platforms – similar to that on Apple's products.
I wouldn't complain about full device encryption either. That's what the planned BitLocker support would bring to the phone.
Quick pointer for today: in modern web development, it is more and more common to specify small image files as inline data. This can be done using the so-called data URLs, which can look like the following:
<img src="data:image/png;base64,A83e1jdi..." />
But the question is, where is this data URL format actually specified? As with many things related to the Internet, the source is one of those RFC documents. In this case, it's RFC 2397 from August, 1998. Yes, almost 15 year ago!
Chances are that NTFS is the main file system on the computer you are reading this and/or developing your code. For years, I haven't personally had the need to format anything except USB thumb drives to anything else than NTFS.
Now, NTFS is a good and robust filesystem in my opinion, but as technology advances, also file systems need to be upgraded. In Windows 8, we are seeing a new filesystem called ReFS.
New features in ReFS include better resilency against hard drive problems, bit rot and the promise of being "always available".
For developers, the new file system would mean that there are less things to worry about then designing systems that need to withstand a wide variety of problems, both software and hardware.
Earlier this week, I was migrating an older ASP.NET application to Windows Server 2008 R2 with IIS 7.5 as the web server platform. The application was a pretty simple one: it basically shared a set of HTML documents with everybody who knew the password. The older platform was IIS 6.0 on Windows Server 2003.
During migration, I also wanted to improve the authentication of the site with traditional ASP.NET Forms authentication. However, by default, ASP.NET web applications only protect .ASPX files from being accessed, but not static content like HTML files and other such files.
How would you go and fix this problem? The easiest way is to add some module handling statements to your web application's web.config file. The following are the ones you need to add:
<system.webServer>
<modules>
<remove name="FormsAuthenticationModule" />
add name="FormsAuthenticationModule"
type="System.Web.Security.FormsAuthenticationModule" />
<remove name="UrlAuthorization" />
<add name="UrlAuthorization"
type="System.Web.Security.UrlAuthorizationModule" />
<remove name="DefaultAuthentication" />
<add name="DefaultAuthentication"
type="System.Web.Security.DefaultAuthenticationModule" />
</modules>
</system.webServer>
If you look at this configuration, it first removes a module, and then adds it again. The modules removed and then re-added are FormsAuthenticationModule, UrlAuthorization and DefaultAuthentication modules. At first, this might look a little counter-intuitive: what does it help to first remove and then add the same module again?
This "magic" works because there is a pre-condition in the default modules that static files are not protected by Forms authentication. This is to keep IIS 7.x working in the same fashion as older IIS 6.0.
To boot, if you simply add the above configurations to your web.config, your web application will only serve static content to authenticated users. By using the regular ASP.NET authorization blocks in web.config under system.web section, you can suddenly limit accessing static content as well.
Note that this configuration only works with IIS 7.0 and 7.5 in the integrated pipeline mode. This pipeline mode is specified in the settings of the application pool that is configured to handle the web application in question.
› Blog Archive