I’ve used a variety of source control systems over the years.  My first experience with source control was with the old Concurrent Versions System, aka “CVS”.  When I first started working at Atari in 1990, the programmers in the TOS operating system group (for the ST computers) were using CVS to manage the source code.  I didn’t immediately adopt it myself, however, because the CVS tools weren’t actually running natively on the Atari quite yet.  The TOS programmers were doing their builds via a TTY connection to a PDP-11 system called “Beauty” that functioned as a file server and build server.

There weren’t really any version control tools running natively on the Atari back in those days, but a few years later I transitioned to using a PC as my main machine. I tried using CVS but didn’t really care for it. Then I had a chance to try out Microsoft’s Visual SourceSafe product, and it became my main source control tool for the next several years.

After Microsoft discontinued Visual SourceSafe, I ended up using Perforce for my own source control needs for many years.  I was happy with Perforce and reasonably proficient at using it.  It worked with Windows and Mac, had a reasonable GUI front-end so I didn’t have to deal with command line tools too often.

Unfortunately, I recently lost access to the server I’d been using for a remote Perforce repository.  I was able to clone everything off before it went away, but until recently,  I hadn’t yet decided what to do about a new remote repository. I could simply run Perforce locally and periodically back it up to the cloud but I wasn’t in any big hurry so I have been experimenting with different setups for awhile.

There have been several I’ve tried that would probably work OK in most respects, but there’s just been one or two small things that I didn’t care for.  Some of the popular source code project websites like Github, SourceForge, or Microsoft’s Codeplex would be fine, except that they are aimed at open source, publicly accessible projects. I like the concept of open source in general, but I work on many projects where that decision is the client’s, not mine. One of my primary requirements is the ability to create projects with restricted access, and with most sites you either just plain can’t do that, or else you can only do it with a paid account. Paid options generally aren’t too expensive, but even $10 a month gets to be noticeable after awhile. Clearly “free” was a desirable attribute, so I have continued to look at what’s out there.

I finally found one I like.

Introducing Visual Studio Online

Microsoft has a website called Visual Studio Online that is designed to help both individual developers and development teams to get the most out of the Visual Studio development environment. One of the nice features is that after you’ve created a free account, you can manage source code projects with their Git source control repositories. Did I mention it was free?

There are other free Git repositories out there, but as previously mentioned, they’re generally aimed at open source and don’t allow private, restricted-access projects. That makes them unsuitable for many developers.  Source control projects on Microsoft’s Visual Studio Online, however, are private by default.

So far I’ve only scratched the surface of the options available with a free account, but Visual Studio Online does offer paid services as well.  If you need more than 5 users on a project or more sophisticated project management tools, they have varying plans starting at $20 per user per month.  There’s also an option that includes a subscription-based license for Visual Studio.  And like most of Microsoft’s other developer stuff, if you’ve thrown a bunch of money at them to become a MSDN subscriber, all of this is included anyway.

This post is aimed mainly at two categories of developer.  Those who haven’t used Git to manage a project before, and those who haven’t used the source control features in Visual Studio. Up until recently I was in both of those categories myself.  My previous experience with Git was mainly limited to using it to download various libraries or open source projects created by others.  I’d never really tried to use it to manage my own projects.

But, after discovering Visual Studio Online’s setup, and having switched over to Visual Studio 2013 last year, I decided to give it a try.

My first project went OK, but when I tried to do it again with another project, I came to the conclusion that I’d gotten lucky the first time around. Maybe it would have made more sense if I’d been more experienced with GIT, but I found the process somewhat confusing.  I went online and browsed around awhile looking for a tutorial, but didn’t find anything that covered the entire process from start to finish.

After banging my head against the keyboard for awhile, I eventually got it more or less figured out.  But since I’d never really found the sort of basic introduction anywhere online, I thought maybe it’d be a good topic to write about.

Install The Git Command Line Tools

Before we do anything else, let’s make sure the Git command line tools are installed.  Go to the View menu and select the Team Explorer item near the top. This will open the Team Explorer view if it’s not already open.  Find that window and click the Home icon from the icons at the top, then click Settings in the next screen.

Once you’re in the Settings screen, near the bottom there should be a section labeled Git, and one of the links underneath it should be Install 3rd Party Tools.  Click that and follow the prompts.

New Project Time

Let’s assume you already have an existing project in VS2013 that hasn’t yet been added to source control.  In the Solution Explorer window, right-click on the solution name at the top, and select “Add Solution To Source Control” from the pop-up menu.


You can also create a new project and select the Add To Source Control option at the bottom right corner of the window.


Assuming that you haven’t gone into the Visual Studio preferences and set a specific source control option, either of these steps will bring up a window asking you to select between the different options for source control.  By default if no add-ons for other systems are installed, you’ll see choices for Team Foundation Server and for Git.  As previously indicated, we’ll be using Git.


A new repository will be created in the solution directory.  You can view the available local repositories by going to the View menu and selecting Team Explorer. Then click the Connect  (electrical plug) icon.  Your new repository should be shown at the bottom of the list of Local Git Repositories.


Now you’ve created a repository for your project, but you haven’t actually added any files to it.  Let’s do that now.  But first, look at the Solution Explorer and you’ll see that some of the entries now have a little plus sign icon at the left side.  This indicates that these files are under source control and that they need to be added to the repository.

Click the Home icon, then select Changes from the window.


This will take you to the Changes screen, where you can commit changed files, or add new ones, to the repository.  You should see a list of the Included Changes, which is the list of files that are about to be added or updated, followed by Excluded Changes, which is a list of other files that Git thinks should be updated, but which won’t be, and finally at the bottom is a list of Untracked Files which are other files found in the project’s directory that are not under source control.


Note that the list of Included Changes shows “[add]” at the end of each line.  This specifies that the file is not yet contained in the repository but will be added.

Now let’s type “Initial Check-in” into the yellow edit box at the top, where it’s asking us to enter a commit message.  Every time you add or update files, you need to include a message of some sort.  Ideally this describes what the changes or additions were, so that three months from now you can figure out what happened.  Once you’ve typed in a message, the Commit button will become enabled.  Click it when you’re done.


Now at the top of the window you should see a message indicating the Commit was created.    You should also see that the plus sign icons in the Solution Explorer window have been changed to little padlock icons.  This indicates that they have been saved in the repository and no changes have been made since.

Note that it also asks you to “Sync to share your changes with the server.”  This is asking us to synchronize with a remote Git server based somewhere on the web or your local network.  If you’ve never done this before (which we haven’t in this example) then clicking it will prompt us to specify the remote server.


And that takes us to…

Visual Studio Online

This is where the connection to Visual Studio Online comes in.  If you haven’t already done so, you’ll need create an account.  (Click here).  Note that you could also enter the name of any other remote Git repository other than Visual Studio Online, but that’s what we’re using for this example.

Visual Studio Online offers a lot more than just a Git repository, by the way, so if you haven’t given it a good look, you really should.

Once you’re signed into your Visual Studio Online account, go create a new project:


This will bring up a pop-up for you to enter information about the new project.  Enter the project name and select Git as the source control method.  Note that there is an option for Process Template that will allow you to select from different development process strategies like Scrum or Agile.  This doesn’t really affect our source control situation, but it does change a few things about how Visual Studio Online otherwise helps you manage the project.  It’s something you might want to take a good look at after finishing this article.


After you create the project, select the Navigate To Project button at the bottom.  Then in the next screen, select Add Code.  This will take you to a screen with important info about the new Git repository that has just been created for your project.


The red arrow points to the URL for the repository.  This is what you need to enter as the “remote server” back in Visual Studio.  So, let’s copy that from the web browser.

Back To Visual Studio

Now we switch back to Visual Studio and paste that URL into the yellow edit field:


After you’ve pasted in the URL, click Publish and your local repository will be copied to the remote one. Note that you may be prompted to enter your login credentials for the Microsoft account you used when you signed up at Visual Studio Online.

This operation is more or less the same as issuing the following command lines from the solution folder:

git remote add origin https://xyz.visualstudio.com/DefaultCollection/_git/pdq 
git push -u origin --all

Where “xyz” is the name of your Visual Studio Online account and “pdq” is the name of the project you created in it.

After The Initial Add & Publish

Once you have added your files to your local repository and published them to the remote one, it’s fairly easy to manage things, at least as far as basic operations like adding new files, publishing updates, etc., are concerned.  Of course if you get into more advanced functions, things get more complex.

We’re not going to get into the underlying methodology of using Git’s more advanced functions in this article. If you want to look at the documentation for it, click here.

Checking out a file for changes is automatic within the Visual Studio IDE.  Simply double-click a file in the Solution Explorer as you always did.  When you’ve changed a file, the icon at the left side will change from a padlock to a red checkmark to indicate that the file is checked out locally and that changes need to be committed.

Now if you go back to the Team Explorer window and look under Changes, you’ll see that there is just one file listed under Included Changes.


Enter “minor changes” as the commit message and then click the Commit button.  It will save the change to the local repository, then give you a link to sync the changes to the remote repository.

You don’t have to sync every commit with the remote repository immediately, but it usually only takes a brief moment so unless you’re offline it’s probably a good idea. Click where it says “Sync” and it will take you to the Unsynced Commits display. Here it will show that there is one local commit awaiting a push to the remote repository. Click the Push button to synchronize the two.

Ongoing Changes & Additions

Once you have committed the changes to a file, it’s marked with the padlock icon again in Solution Explorer. It will remain that way until you open it and make changes again.  Even if you make changes using an external program, Visual Studio will notice and mark it with the red checkmark.

As you create new files within your project, they’ll initially have the little plus sign icon until you have done a Commit operation that adds them to the repository.

In Conclusion

In a future article we’ll discuss more advanced topics like creating a code branch and how to reconcile multiple versions of a file which have been changed by different users.

The Git tools within Visual Studio aren’t necessarily the most sophisticated, but they’re sufficient for most basic operations.  You can always use other popular tools for Git management such as SourceTree or the Git command line tools.  There are also a variety of extensions for Visual Studio that provide additional functionality.

Most importantly, if you’re an individual developer who hasn’t been in the habit of using source control, you really need to reconsider that idea. My guess would be that you’ve avoided it because it just seemed like too much extra work.  Easier just to ZIP up your source code directory and save it to another drive, yes?

No, not really. The tools built into Visual Studio minimize the extra work you’ll need to do, and the advantages to using a source code control system are more than worth it.  Don’t forget also that you can use the source control functions with any sort of Visual Studio project.  Even if it’s just a plain HTML website.

When I started working more with ASP.NET a couple of years ago, doing a couple of complete websites from scratch, rather than working from an existing template or someone else’s site, I soon ran into the error shown below. While trying to troubleshoot it I came to the conclusion that it’s both very common and yet not very well understood.  Eventually I figured I had a good handle on the whole thing so I thought maybe it was time to share.

Here’s the error you get from IIS:

Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.Web.HttpException: Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.

To simplify what’s happening, the error occurs because the client and server aren’t using the same key to encrypt & decrypt data that gets sent back and forth by ASP.NET.

So, how does that happen?  The message refers to the  entry in your ASP.NET website’s web.config file.  This entry defines how ASP.NET gets the encryption key used to encrypt and decrypt data sent back and forth in ASP.NET.  The default configuration for  is to specify ASP.NET should automatically generate the key. When AutoGenerate mode is turned on, the key is generated at the start of the browser session and in theory should last as long as the user’s session with the browser is open.

It makes perfect sense that when you have multiple servers working together, you have to synchronize them in certain ways, such as making sure they all use the same encryption key.  So turning off AutoGenerate would make sense in that scenario.

But I was using a single, stand-alone server, not a cluster or farm, so the message didn’t seem to apply.  Oddly, the information I could online seemed to largely ignore this alternative.

After experimenting with it for awhile, I came to the conclusion that the problem can also be caused by the expiration of the session on the server side. This can happen for a variety of reasons, but the most common would be simply that the client side sits idle long enough.  Like, you know, if the user walks away from their computer at bedtime, leaving the site open in their browser window.

After the session has been inactive for awhile, the server purges it in order to recover the memory and any other resources that might be involved.  Later, when the user comes back to the computer and does something that causes an event, the JavaScript code that ASP.NET uses to do its magic will still have the old encryption key from the night before. When it sends data to the server, the server will create a new session, since the old one was purged.  But the new session will have a new encryption key that doesn’t match what just came in from the client, so it spits out the error.

Aside from the user being idle for awhile, there are other scenarios which can cause an open session to be reset, such as files in the website being updated, user’s authentication status changing, or the user’s internet connection changing in some way, to name a few possibilities.

When the session gets reset, the appearance of the error depends on what happens next.  If the user clicks a plain old fashioned link to another page, the error will not occur, since this does not require any encrypted data to be sent back to the server.  However, if the item being clicked is an ASP.NET HyperLink control or something similar where an event is generated, then the client will send encrypted data and the server will go boom.

Annoyingly, there appears to be no way to catch this error and recover from it once it’s happened, at least that I’ve found.

But the fix is simple.  Just always use a specific Machine Key configuration with your ASP.NET websites, rather than AutoGenerate. There is a web-based tool for creating a unique Machine Key available online.

A Brief Sidebar About The ASP.NET Page Life Cycle

These days there are a few different flavors of ASP.NET out there.  The original flavor is commonly known as “Web Forms”. Subsequently Microsoft has come up with ASP.NET MVC and Razor.  These newer flavors do things a bit differently in some ways, but this article is mainly about the original “Web Forms”.

When I first hit this error, I was still relatively new to ASP.NET and didn’t have a full understanding about the relationship between the server and client sides.  If that applies to you, then read on and I’ll try to explain a few things so you have a background for what’s happening with the error.

When your page is first loaded, ASP.NET creates an instance of the class which is attached to the page and then calls the methods named Page_Init and Page_Load to handle whatever processing is required to create the page.

Part of what gets created during this process is a block of JavaScript code which handles the client-side part of ASP.NET.  This includes a data structure called the viewstate which describes the status of all controls on the page which have the runat=”server” attribute assigned to them, regardless of if they are plain HTML tags or something ASP.NET specific.  This attribute means that when some sort of event occurs on the client side, we want to have it processed at the server side. The ASPX source file for the page can assign handlers for these events, or your Page_Init and Page_Load code can do it.

An event handler is a method (usually within your page class) which knows how to process the event in question. Whenever some event happens on the client that needs to be processed on the server, the ASP.NET JavaScript code updates the viewstate data, then encrypts it and sends it to the the server along with a description of whatever event occurred.  This whole process is known as a postback.

On the server side, when a postback happens, the Page_Init and Page_Load code for the current page is called again, just like it was when the page was first created, except now the property IsPostback is set to true, whereas it had been set to false originally.  Your page’s code can look at this value to determine if there is extra processing required for the postback, or if there something that can be skipped.

After the Page_Init and Page_Load code finishes, then ASP.NET calls the function that was designated as the handler for the event which occurred.  It might handle a button being clicked, or whatever else was done.  After this processing is done, unless the code redirected to another page, the updated viewstate structure is returned to the client, which then decrypts it and updates the window contents as indicated.

July 5th, 2014 by Mike Fulton
Categories: .NET Programming, C# Programming, Windows

I’m not ashamed to say it… C# is my favorite programming language these days.  It wasn’t always so.  In fact, I didn’t pay a lot of attention to the C# programming language when Microsoft first introduced it in 2000, mainly because I initially looked at it as being essentially Microsoft’s attempt at an alternative to Java.

It’s Really Just “Microsoft Java” Isn’t It?

Yeah. Kind of.

Well… no, not really.  But it’s easy to think that if you don’t look too close.

In the early days of C# this was a common question, and it was fueled at least in part to the fact that Java creator James Gosling referred to C# as an “imitation” of Java.  As I said above, I have to admit that’s how I thought of it initially myself.

In terms of the basic language syntax, C# is pretty darn similar to Java.  And yes, the combination of C# and the .NET framework is in some ways similar in concept to the Java language and runtime environment, albeit perhaps more in the early days than now.  However, as I’ve become more experienced with both environments over the years, I’ve become more and more aware of the differences, and they can be pretty significant. I’ve come to the conclusion that C# is no more an “imitation” of Java than Java is an imitation of C++.  They have similar design goals in many respects, and a similar heritage, so of course they’re going to be pretty similar.  But ultimately, C# and Java are really more like close cousins than twins.

The Real Microsoft Java

When Sun Microsystems released Java in 1995, it seemed like a very interesting new language and it got a lot of attention in the computer industry press as well as in the mainstream.  However, it simply didn’t seem like it applied to any of the projects I was doing at the time. I ended up writing a few goofy little applets for one of my websites, but that was about it.

Sun told the world that Java was free for everybody to use, so a few years later, Microsoft came out with their own implementation of Java called J++ which used Microsoft’s own virtual machine and runtime support. To nobody’s great surprise, Microsoft’s runtime was different from Sun’s in that it facilitated the use of Microsoft technologies like Active-X.  And Microsoft’s J/Direct framework gave the J++ code access to the underlying Windows API, bypassing Sun’s class libraries.

Microsoft wanted to position J++ as a way to use the Java language for Windows-specific development, but that idea didn’t sit very well with Sun. Their philosophy was that Java should always be as platform-independent as possible and they felt that Microsoft’s efforts, should they succeed, would end up making developers and their code dependent on Microsoft’s platform and tools.

Despite Java being free, Sun had kept a very tight grip on how it was supposed to work, and they claimed Microsoft wasn’t playing by the rules. In particular, in order to use Sun’s “Java” trademark in any fashion, all implementations were required to be 100% compatible, and Microsoft’s version of the runtime didn’t pass Sun’s Java validation tests.

Lawsuits… many lawsuits.

Scratch J++, Enter C#

At the start of 1999, the lawsuits over J++ were still going, but Microsoft was losing ground.  Java had gained popularity, but few developers were doing much with J++.  It wasn’t the big success that Microsoft had hoped.

No doubt there were also many web developers who simply agreed with Sun’s philosophy regarding cross platform compatibility, but it was thought by many that the compatibility problems were introduced deliberately because Microsoft wanted to kill the Java platform.  That first part was never established in court, but there was plenty of evidence for the second part.

Meanwhile, Microsoft had been working on a new system frameworks they were calling Next Generation Windows Services. The new frameworks which would ultimately be known as “.NET”.  You may have heard of it.

At the heart of the new system was the Common Language Runtime (CLR), a new virtual machine that was responsible for running .NET programs. One of the major design considerations of the CLR was avoiding many of the common flaws found with existing programming languages, so that meant that new compilers would be needed.  Microsoft launched the “Cool” project at the start of 1999. Cool was designed to be a managed language that would follow the general example of C and C++ syntax.  In fact, the project name stood for “C-Like Object Oriented Language”.

Because of trademark issues, the “Cool” language was later renamed to C#.

When Microsoft first started talking about the .NET framework, the name had many people thinking that it was a web-only thing, and I have to admit that was my own first impression.  The use of a virtual machine sparked comparisons with Java, and when the new C# language was added to the discussion, it looked like Microsoft was trying to redo J++ in a way that didn’t rely on Sun for anything.

In truth, however, the use of a virtual machine was a tried and true technique that Microsoft had been using for years before anybody ever heard of Java.  The development of  .NET, C# and the new Common Language Runtime (CLR) had a broader scope and much bigger goals than being a Java knock-off.  If you want to learn more, check out this interview with the creator of C#, Anders Hejlsberg, and this one too.

Switching From C++

Despite my misgiving about finding a use for C#, I bought one of the first books released to learn more about it. As I dug deeper, it became clear that the language actually had a number of significant differences from Java.

However, it wasn’t clear that the likely applications of C# were much different, and because the .NET runtime was still in beta, the whole thing just didn’t really seem like it was ready for prime time quite yet. So I waited.

At that point in time,  my Windows-based programming was mostly centered around creating and maintaining GUI-based desktop applications and command-line utilities, using Visual C++ and the Microsoft Foundation Classes (MFC).  I had been using VC++ and MFC since they were first released and was very comfortable with the environment.

However, I wasn’t completely happy with the VC++/MFC environment in some respects, which is why I had my eye out for alternatives.

The first problem was that any project I did with MFC seemed to have memory leaks.  Not necessarily hugely significant ones, but every time I ran a program under the debugger, I would get a length report at the end about memory issues.  The first few times I saw this, I spent a lot of time trying to find the cause in the debugger.  Eventually I discovered the problem would occur even with code that was generated entirely by Visual Studio, so it was apparently something with the MFC libraries and not my code.

That didn’t really make me feel better.

When C# was included in the Visual Studio 2002 release, the .NET framework was far more mature, and its usefulness was more apparent.  It had things like a regular expressions library that was missing from the standard VC++/MFC setup, to name one example. Eventually I started adding calls into the .NET framework from my C++ projects.  The VC++ interface to accessing managed code in the .NET framework was a bit clunky, but it worked.

I still hadn’t found a use for C#, however.

Finally C#

A few years later, I started doing more web-oriented programming that went beyond Flash or client-side Javascript. At first I was using mostly PHP, but eventually I ended up doing some code maintenance on a few projects that used ASP.NET. The projects themselves used Visual Basic, not C#, but it gave me a good excuse to spend some time learning about the ASP.NET environment in general, and I did most of my experimenting with C#. It took me awhile to warm up to the ASP.NET environment, but the more I used the C# language the more I liked it.

Along the way, I finally had some projects where Java was called for, because of a need for cross-platform compatibility.  Then it finally happened… a new project where I could use C#.

I had a legacy project done with Visual C++ and MFC that needed to be updated to access a SQL Server database across the local network instead of reading and writing data files.  The program needed to be able to run on multiple stations at once and share data between them.

I got it working, but I really wasn’t very happy with the way that the database stuff worked.  To be fair, some of that was due to the way the database support got bolted onto the existing project, but I didn’t really care for the way the API was setup either.

After the update was finished, the client had a brand new list full of new features they wanted to implement in the application, and they also wanted to create a new website that accessed the same database. Maintaining the existing C++ project and adding the new features was doable, but when the website idea was thrown into the mix, it didn’t look like a good idea. We decided to redo the application in C# and use ASP.NET for the website.  A lot of the existing C++ code could go into the new version without much change, but things like the database code could be drastically improved by the rewrite and then shared between the two projects.

I was much happier with the way the database connectivity worked in C# and .NET, but writing the database code in C# only for the website and maintaining that in parallel with the C++ code for the application would have been twice as much work overall.

As I started the new C# version of the application, my initial concern was making the transition from using MFC with Visual C++ for the user interface design and coding.  Especially since the client wanted the existing user interface to stay pretty much the same. The first thing I had to decide was if I should use Windows Forms or Windows Presentation Foundation (WPF) for the user interface.

Windows Forms had been around for awhile, and most of the books I’d read about C# had used it for whatever GUI samples they might have.  In fact, I’d recently bought a pretty decent book that focused entirely on it. (Windows Forms 2.0 Programming) That was a big plus.

At the time, Microsoft had only just released the first version of Windows Presentation Foundation and there weren’t a lot of books or other information about it yet.  It looked like it had more power and flexibility overall, but also like it would take more time to learn.

Since I was mostly replicating the existing MFC-based GUI I decided to go with Windows Forms.  The GUI creation tools for Windows Forms were a lot like the Java Swing GUI builder tool in the Net Beans or Eclipse IDEs, which I had recently become familiar with. It turned out that it was very easy to make the transition and it really didn’t take me very long before I was more productive than I’d ever been with MFC.

So How Is C# Different From Java?

I’m not going to make an attempt to enumerate a list here, nor try to keep track of which version of C# versus what version of Java is being discussed, and so forth.  Rather I’m going to try to cover some of the basic differences.

First, I would have to say that Java is arguably more concerned with keeping developers out of trouble at all costs than is C#.  A good example of this is the way that C# allows you to mark off a block of code as “unsafe”.

Normally in C#, using C-language style pointers and related pointer operations is not permitted, just as in Java.  Much of the time this is not an issue, but there are times when you just have no choice, so C# allows use of the unsafe keyword.  By marking a function or code block as “unsafe”, you’re permitted to use C-style pointers and pointer operations on memory.

Under the right circumstances, this allows you to do certain things much, much faster than would be the case with “safe” code. Perhaps most importantly, you don’t have to use a different compiler or programming environment to write, compile, and possibly debug what might be no more than a few lines of code. You can do all that within the main project and go back and forth between the “unsafe” code and the rest of the project pretty seamlessly.

The requirement of placing such code in an “unsafe” block means programmers are much less likely to do something wrong accidentally, but it’s a relatively easy thing to do when you need it. Not so with Java. To do something functionally like an “unsafe” block would require you to write code in another language like C, compile it, and then tell your Java project where to find it.  After all that, then your Java code could call that external function via the Java Native Interface (JNI).

It’s a lot of steps, involves extra tools, and it’s a sufficient pain in the butt that most Java programmers don’t do it unless they expect a rather substantial difference in performance or unless they simply have no other choice.

What’s Missing?

Surprisingly, there are some rather significant items for which C# and .NET languages in general don’t play quite so nicely with. It’s not always a huge problem, but there are things which require the programmer to jump through a few extra hoops to access WIN32 calls or to use 3rd party tools because Microsoft has not made them accessible directly via .NET.

DirectX, the game programming API, is perhaps the biggest example. The lack of a managed version of DirectX means that if you want to write a game for the Windows 8 app store, for example, you have to do it using Visual C++ instead of C#.  Officially, anyway.

Although there was supposed to be an official Microsoft managed version of DirectX at one point, that project seems to have disappeared.  Instead, we have a couple of open source projects like SharpDX and SlimDX which provide access to DirectX.