Back to Blog index.
Earlier this week, I learned about a new product called Crypto Obfuscator For .Net 2010 that is able to encrypt and obfuscate .NET assemblies (.exe and .dll files).
I haven't yet tested the product, but I'd say it surpasses the simple obfuscator that comes with Visual Studio. Check the product out if obfuscation is something you'd like to do.
Visual Studio 2010 and .NET 4.0 are being developed as we speak, and today I wanted to share to quick links to information about new features in these coming releases.
First, check out the post about Entity Framework in .NET 4. Secondly, check out what is being said about Extensible Output Caching with ASP.NET 4.
Happy reading!
It's now a new decade, and suddenly everything written, designed or programmed in 2002 (let alone in 1992) looks old, rusty, and maybe not up to today's standards. If a software written in 2002 fails, developers have the tendency to say, "Yeah, but it's almost ten years old now." But once 2020 is here, we might feel exactly the same about software we write with latest standards of today.
Still, lots of software that we write today, will be in production in ten years. In fact, lots of software written in 2002 will be in production, too. And maybe even code from the 1990s (yikes).
A little forethought leads us to ask the question: how could we write software that can meet the requirements, operate and still be maintainable in ten years or more? What are those design principles that avoid developers to escape that dreaded maintenance nightmare old code often causes?
Of course, this is a much broader topic than can be discussed in a single blog post, but I wanted to list four choices that in my opinion lead to applications that stand the test of time, are maintainable, and have an upgrade path. These are:
1. Tools, languages and platforms come and go. Choosing a programming language, development IDE and even the underlying operating system/platform is fundamental choice that affects the resulting application in many ways. However, no tool, language or platform is immortal. Visual Studio, .NET and C# might be the choice of today, but how about in 10 years? The bottom line: choose wisely. A broadly-adopted language/tool/platform is often a safe choice. You might lose a bit in the cutting-edge productivity, but in the long run, you usually gain.
2. Focus on a loosely-coupled architecture that allows change. There are two important words to note: loosely-coupled and architecture. By loosely-coupled I mean applications that take the possibility of change to the heart. Just like tools and languages can change, so can databases, patterns and user management, for instance. Instead of tightly-coupling everything into a big snowball that is impossible to stop once rolling down the hill, focus on lightweight parts, that can be changes almost at will. Naturally, some things need to stay fixed, but many parts of the application should be switchable to something else.
The other word was architecture. Yes, your application needs an architecture, and it's better to have one that works. As well as on the coding level, keep in mind the possibility of change on the architecture level, too.
3. Keep things simple. We developers could talk day-in day-out about the best programming language, features thereof, ingenious ways to solve a problem, and so on. But in the end, maintainable code is often about simplicity. Often those who are assigned the tasks of maintaining code are not those who wrote it in the first place. Thus, the original developer's logic might not be immediately clear to you, especially if there is no documentation (how often do you see a coding project with too much documentation?). Although it is indeed nice to prove your technical ability with clever coding tricks, basic code is often the best when it comes to understanding it. Because if you don't understand the code, it will be difficult to maintain.
4. Document and record the expectations. Yes, documentation is often the last step in a development project, but this need not be the case. In addition to clear documentation (especially, remember to write down why something was done, instead of just how), make sure you record in some way or other, the expected results of your applications input and output. Unit tests are a great and modern way to do this, but the problem is that unit tests are often related to the tools you use. It's probably also worthwhile to record the broad expectations on paper documentation as well.
With these four tips, I believe many applications would become more robust to the changes that the day after tomorrow mandates. If you are already using all of these techniques in your own development projects, then great! In my opinion, you're all set to the new decade!
PS. In the business world, performance is often evaluated with a so-called scorecard (in good and bad). A software audit could create a similar "scorecard" on software future-proofness. Stay tuned for more ideas about this later.
The Prosessori magazine here in Finland has published two of my articles, one column about embedded Windows versions and another, a feature article about Visual Studio 2010 Beta 2. Both articles are one-pagers, and are titled "Visual Studio menee pilveen" and Sulautetut hyppäävät Vistan ohi suoraan Seiskaan".
Happy reading!
Especially in the U.S., Twitter is a popular microblogging platform. If you are used Twitter already, chances are that you are using some third-party application to update your status on your Twitter account. And if you're a developer like me, then the question of updating Twitter tweets from your own .NET application might arise.
Twitter itself contains a nice set of developer documentation, which points to a set of third-party libraries that can update Twitter feeds. For .NET developers, some of the most popular ones include TweetSharp, Twitterizer and Yedda.
If you want to update Twitter feeds from your C# code, you could start with these libraries. The other alternative is to write everything from scratch. For that, check out the API specifications.
For a long time, unit testing software applications was something that only those interested in latest trends or academia did. Today, unit testing can be said of as being a mainstream technology, and even the smallest ISVs are focusing on it. For .NET developers, both Visual Studio 2008 and 2010 have great support for unit testing right out of the box, if you are using the Professional editions or above.
In simple terms, unit tests can be thought of as a safeguard against future code changes. Often as projects become larger, the fear of change can affect future enhancement possibilities, because developers are afraid to break something that already worked. Unit tests can lessen this fear.
Now, unit tests cannot be something that you glue in later once you are done with your coding. Instead, you should plan for testability while writing your code. On the other extreme, the TDD (test-driven development) writes unit tests even before the actual code. In any case, you will need to write code and use architectures that help in achieving your goal.
One of the coding-side enablers in testability is Dependency Injection or DI. You might have heard the term, and maybe even have used it even if you are not aware of the term. The basic idea of Dependency Injection is that you should write code that is loosely-coupled, and objects should not expect specific object types to communicate with each other. Instead, you should interfaces for more generic usability.
This generic model is very important so that you can use mock objects to help in the testing in place of real object types that can be difficult to automate and/or test in tandem. Wikipedia for instance has an article about Dependency Injection, and so does MSDN Documentation.
In addition to the concept of Dependency Injection, there are many ready-made frameworks for C# and .NET developers that can be used. Three of the popular ones include Unity, Spring.NET and to certain extent Managed Extensibility Framework or MEF.
If you are interested in code testability, but are not yet familiar with the concept of DI, now it's a good time to start learning. Lots of material is already available, so take use of it!
Recently, I needed to set up a 64-bit Windows Server 2008 R2 server from scratch. Installing Windows is nowadays very easy, and doesn't require many steps. Basically, it's just a matter of putting the DVD into the drive, booting, answering a few questions, and then taking a break/nap/C64 emulator session/watercooler chat/cup of coffee for about 20 minutes.
Once the setup is done, the usual next step is to configure few details, enable some roles such as Hyper-V and IIS 7, and then proceed to install applications. If you are like me, you are probably going to use a remote desktop connection to manage your server once you connect it to the network. Since you might not have a suitable file share set up at this point, you might do what I did: enable the remote server session to access local drives from the host computing. This way, you will get access to the installation files from the host PC (the one next to which you are sitting), and then see those files as a network share or drive on the server machine.
All this is very simple to set up (go to the Remote Desktop Connection utility's Local Resources tab, and select Local devices and resources). But, if you try to launch a setup application from the TSCLIENT share, you might get the following Windows Installer message:
[Window Title] Windows Installer [Main Instruction] The Windows Installer does not permit installation from a Remote Desktop Connection. [OK]
This happens because Windows Installer does not support installing from the "fake" network share created by the remote desktop client (mstsc.exe). A Microsoft Knowledge Base article 927063 talks about this error, but offers in my opinion somewhat complex solutions.
The easy solution: simply copy your installation file (hopefully it isn't overly large!) onto the desktop (using the remote desktop network share; this works well) and then install from the desktop.
Problem solved!
New information about Visual Studio 2010 and .NET Framework 4.0: these two will launch on April 12th. So, not a long time to wait, it seems. But a Release Candidate version must come first.
The original source is an MSDN blog post by Ron Caron.
Microsoft has recently updated a long list of Windows 7 compatible applications. The list contains information about well-known applications and dozens of more, and includes information about both 32-bit and 64-bit applications
If you are developing software, make sure your's is on the list. Or better yet, certify your application!
Some hardware information for a change, something that all developers should be aware. I'm sure you've heard of Intel's "Nehalem" products, like Core i7 desktop processors and their server counterparts, Xeon 3500 and 5500 series.
If you are thinking of a new workstation or a server, these new processors are simply great, with lots of number crunching power. But, what is the difference of these models? I won't go into nitty-gritty detail here, but shortly put, the i7 series (especially the 9xx line) is aimed at high-end workstations and the Xeons are for servers.
But what do the server processors have in addition to i7, as the price is steeper? Shortly put, Xeons support error-correcting ECC memory. If you need that, you must get a Xeon. Second important difference comes from the support for double-processor systems. Only the higher model number Xeon 55xx supports that. The cheaper 35xx models only support single socket systems.
Short news for today: Microsoft today announced that they have joined the W3C's standardization organization's SVG (Scalable Vector Graphics) working group. Apparently, the plan is to include support for SVG graphics in future Internet Explorer (IE) versions, but of course this is just a start for the work.
Microsoft's Windows Azure is now in production, and at least the most important features can now be used commercially.
Also, Microsoft has finally announced the Euro prices of Azure; previously only USD dollar prices were available. There are some introductory prices going on, but the regular prices can be seen here when you choose an European country, such as Germany or Spain.
For instance, the Windows Azure computing time is € 0.0852 per hour on Small Instances.
If you are still using an older SQL Server version such as 2005 (or even 2000), there's one change in lock handling in SQL Server 2008 that makes things work differently in the latest version.
According to a Connect post, lock escalation with INSERT statements now works differently. Depending on your situation, this might or might not affect your application. It's better to be safe than sorry, though.
Welcome New Year and 2010! If you can read this post from your RSS reader, then you have successfully updated the URL or this blog. Congrats!
A new year is always full of possibilities, and this time I though I'd try to predict the future and the coming .NET development trends. This is always a somewhat futile attempt, but even so, it is great fun, so I'm going to give a try. Here goes a quick list, in no particular order:
Of course, there's also a lot more to predict, but these trends will probably show their heads this year. We'll see how it goes. Also, remember to let me know what you think!
› Blog Archive