Using Multi-Core JIT from .NET 4.0 if .NET 4.5 is installed

.NET Framework 4.5 contains a very cool new feature called Multi-Core JIT. You can think of it as a profile-guided JIT prefetcher for application startup, and can read about it in a few places …

I’ve been using .NET 4.0 to develop Paint.NET 4.0 for the past few years. Now that .NET 4.5 is out, I’ve been upgrading Paint.NET to require it. However, due to a circumstance beyond my control at this moment, I can’t actually use anything in .NET 4.5 (see below for why). So Paint.NET is compiled for .NET 4.0 and can’t use .NET 4.5’s features at compile time, but as it turns out they are still there at runtime.

I decided to see if it was possible to use the ProfileOptimization class via reflection even if I compiled for .NET 4.0. The answer: yes! You may ask why you’d want to do this at all instead of biting the bullet and requiring .NET 4.5. Well, you may need to keep your project on .NET 4.0 in order to maintain maximum compatibility with your customers who aren’t yet ready (or willing Smile) to install .NET 4.5. Maybe you’d like to use the ProfileOptimization class in your next “dot release” (e.g. v1.0.1) as a free performance boost for those who’ve upgraded to .NET 4.5, but without displacing those who haven’t.

So, here’s the code, which I’ve verified as working just fine if you compile for .NET 4.0 but run with .NET 4.5 installed:

using System.Reflection;

Type systemRuntimeProfileOptimizationType = Type.GetType("System.Runtime.ProfileOptimization", false);
if (systemRuntimeProfileOptimizationType != null)
{
    MethodInfo setProfileRootMethod = systemRuntimeProfileOptimizationType.GetMethod("SetProfileRoot", BindingFlags.Static | BindingFlags.Public, null, new Type[] { typeof(string) }, null);
    MethodInfo startProfileMethod = systemRuntimeProfileOptimizationType.GetMethod("StartProfile", BindingFlags.Static | BindingFlags.Public, null, new Type[] { typeof(string) }, null);

    if (setProfileRootMethod != null && startProfileMethod != null)
    {
        try
        {
            // Figure out where to put the profile (go ahead and customize this for your application)
            // This code will end up using something like, C:\Users\UserName\AppData\Local\YourAppName\StartupProfile\
            string localSettingsDir = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData);
            string localAppSettingsDir = Path.Combine(localSettingsDir, "YourAppName");
            string profileDir = Path.Combine(localAppSettingsDir, "ProfileOptimization");
            Directory.CreateDirectory(profileDir);

            setProfileRootMethod.Invoke(null, new object[] { profileDir });
            startProfileMethod.Invoke(null, new object[] { "Startup.profile" }); // don’t need to be too clever here
        }

        catch (Exception)
        {
            // discard errors. good faith effort only.
        }
    }
}

I’m not sure I’ll be using this in Paint.NET 4.0 since it uses NGEN already, but it’s nice to have this code snippet around.

So, why can’t I use .NET 4.5? Well, they removed support for Setup projects (*.vdproj) in Visual Studio 2012, and I don’t yet have the time or energy to convert Paint.NET’s MSI to be built using WiX. I’m not willing to push back Paint.NET 4.0 any further because of this. Instead, I will continue using Visual Studio 2010 and compiling for .NET 4.0 (or maybe I’ll find a better approach). However, at install time and application startup, it will check for and require .NET 4.5. The installer will get it installed if necessary. Also, there’s a serialization bug in .NET 4.0 which has dire consequences for images saved in the native .PDN file format, but it’s fixed in .NET 4.5 (and for .NET 4.0 apps if 4.5 just happens to be what’s installed).

19 thoughts on “Using Multi-Core JIT from .NET 4.0 if .NET 4.5 is installed

  1. Brian says:

    > So, why can’t I use .NET 4.5? Well, they removed support for Setup projects (*.vdproj) in Visual Studio 2012

    .Net 4.5 may be used outside of Visual Studio 2012. The compilers are freely available without any dependency on Visual Studio 2012. The same goes for MSBuild. (I have not tried yet, but I bet with a little effort, you could even compile .Net 4.5 within Visual Studio 2010.)

    However, the bigger question is why you are still relying on the obsolete Setup projects. Microsoft has said for YEARS that they will be removing them. WIX has been pushed for years as the replacement, and most of the community has switched. I say good riddance: the old setup projects were terrible. Once you try WIX, it’s hard to ever consider anything else.

    • Rick Brewster says:

      Obsolete? Years? I guess I didn’t get the memo (and I work there!). This sucks because they work just fine for many types of projects. I’m using it because it was there and I’ve always used it, and WiX wasn’t even around back then. Yes it was terrible in some ways but Paint.NET’s needs were just barely within what it could do, and I never really had to ever modify anything about it. So let’s see: 1) it worked, 2) it never really bothered me, 3) I don’t want to be a Setup Engineer, I just want to write app code. I don’t want to learn WiX just like I don’t want to be a Database Consultant. And I’m sure there’s some way to graft .NET 4.5 on to VS 2010 but gosh … that could also be hours flushed down the drain which would be better spent on writing real code. At this point in the release cycle I can’t take any side trips like that.

  2. BlueRaja says:

    I also did not know setup projects had been obsoleted. Is WiX as easy to figure out as the Setup Projects (it only took me a few minutes to setup a .msi for my project, without having to read any documentation)? Is WiX even *included* in VS? I thought it was a separate, non-MS project

  3. Schniefelus says:

    hey rick, what’s going on with paint.net 4.0, do you think the releasedate in 2012 is still realistic? will you release a beta version?

  4. Easy says:

    if you are not doing it now on 4.5, you have to do it later …
    Will you let influence you from windows 8 style? Metro for PDN?

    Btw can you please change the default recording area from 800×600 to 1024×576? Or make it changeable?

    • Rick Brewster says:

      re: “you will have to do it later”. Yes, that’s true. This is something I’m doing to optimize the release date of Paint.NET 4.0. And it should be okay since I don’t really need any .NET 4.5 features yet.

      As for Metro, the plan is that PDN4 on Win8 will have a native look and feel with Metro styling, but it will still feel native on Win7 w/ Aero styling.

  5. Maciej says:

    “However, at install time and application startup, it will check for and require .NET 4.5.”
    Why require .NET 4.5 since Paint.NET will be compiled to 4.0? .NET 4.5 doesn’t work on XP so still a large user base wouldn’t be able to upgrade. You should at least lave the (old) 4.0 version available side by side with the 4.5 version.

    • Rick Brewster says:

      Dude just upgrade to Windows 7 already. XP is like 100 years old now. I announced a very long time ago that Paint.NET 4.0 would require Windows 7. It’s using Direct2D, among other things, and would not work on XP anyway.

  6. Maciej says:

    I don’t have Windows XP but my clients do. And since 4.5 is an in-place upgrade I don’t want to hide bugs that may appear in production, so I won’t install. Just consider leaving version 3 of Paint.NET after version 4.0 will see the light of the day.

    • Rick Brewster says:

      You can also try what many other developers in this situation do: keep a copy of XP on another computer or in a virtual machine. As much as you probably need to support XP + .NET 4.0, you are also going to need to support Win7 + .NET 4.5. If you stick with Win7 + .NET 4.0, you will wind up in a minority niche as the developer on a platform combination nobody else is actually using and making inferences about your product’s quality (stability) that may not reflect reality.

      In any case, I’m sick and tired of talking about and being badgered about what .NET or Windows version is going to be supported. No more questions or comments on this please, as they are an incredible waste of time. (This isn’t specifically in response to your comments, Maciej, I mean this universally)

Comments are closed.