Hack Alert: Compile with .net 4.6!

[wbennettjr]

************************************************** ************
* DANGER danger DANGER danger DANGER danger
*
* This technique can screw up some programs if not
* properly followed.
*
* Thar be dragons. Caveat emptor.
* If you squirm when babies cry, this post is not for you!
* If you feel like a murderer for stepping on an ant, this post is not for you!
* If you argue with people talking in their sleep, you're just weird ... continue
*
* DANGER danger DANGER danger DANGER danger
************************************************** ************

Still here? Ok, then. Onward fellow brave and bold miscreant!

Since this technique is dangerous, I'll try to explain in detail so you have a full understanding of the issues and the solution. This way you will know how to undo the changes and be able to come up with other solutions if you desire. If you wear Nikes and don't want to read through my ramblings, fine, just do it already - jump to the Instructions section below. I won't provide a ton of help with this. This is an advanced procedure for people who fully understand the risks and dangers. If you can't follow along, chances are you shouldn't be doing this <wink/>.

A little background/context:

As long as you are using assemblies dynamically (which NT does for the NinjaTrader.Custom.DLL), you can mix and match framework versions. The other assemblies won't care what version of the framework the assembly is compiled against - just as they don't care what compiler was used to compile a used C++ DLL.

NT is hardcoded to use .net 4.5. For the simple case, all indicators and strategies end up in the NinjaTrader.Custom.DLL. This is the DLL that we want compiled with .net 4.6 - NT itself is precompiled for .net 4.5.

Various solutions and limitations:

1. Compile the custom DLL yourself and place in the Custom folder
   • When you make changes in NT, it recompiles and replaces the DLL
   • NT locks the file so you have to shut down NT to replace the DLL (Why does it do this? Doesn't NT shadow copy this? Hint, hint to any ninjas reading)
2. Change NT so there is an option to select which compiler to use
   • Well, apparently, the ninjas won't let us choose: http://ninjatrader.com/support/forum...ad.php?t=79272

Solution description:

I think option 2 is the best solution - that is what this hack is based on. The basic flow of operations is as follows:

.........................................Installed Frameworks
.....................compile.............. .net 3.5
NinjaTrader.....==>................. .net 4.5
............................................... .net 4.6

What we want is:

.........................................Installed Frameworks
.....................compile.............. .net 3.5
NinjaTrader............................. .net 4.5
..config (4.6)....==>................. .net 4.6

Since the ninjas won't let us choose, we have to force them to choose! They may have shurikens but we have guns - and we have to bring out the big gun (the BFG for you Doom fans ). The answer came to me when I remembered a trick I did back in high school to hide my games from the teacher (ah, the good 'ol days... but I digress, that's another story). So... what do we do? We use classic injection:

.........................................Installed Frameworks....................Installed Frameworks
.....................compile.............. .net 3.5............................................. .net 3.5
NinjaTrader.....==>................. .net 4.5 (inject csc.exe ) |.............. .net 4.5
............................................... .net 4.6............................... ==>....... .net 4.6

The attached code is for a csc.exe (the CSharp compiler) replacement. It checks to see if it's being called by NT8 and re-directs to the .net 4.6 csc.exe version if that's the case; otherwise, it calls the original .net 4.5 csc.exe.

Instructions:

1. Create a new console application
2. Delete the class1.cs file
3. Add the files from this post
4. Compile a 32 bit and a 64 bit version of the application
5. Use the following steps to replace csc.exe in the framework folder with the application (This is a dangerous step. Follow carefully! Backup all folders in case you make a mistake):
   • Use the following steps to replace the csc.exe file in the framework 32 bit folder:
     1. This is usually in "%windir%\Microsoft.NET\Framework\v4.0.30319"
     2. Rename csc.exe to csc.original.exe
     3. Rename csc.exe.config to csc.original.exe.config
     4. Copy your 32 bit .exe into the folder and rename it to csc.exe
   • Use the following steps to replace the csc.exe file in the framework 64 bit folder:
     1. This is usually in "%windir%\Microsoft.NET\Framework64 \v4.0.30319"
     2. Rename csc.exe to csc.original.exe
     3. Rename csc.exe.config to csc.original.exe.config
     4. Copy your 64 bit .exe into the folder and rename it to csc.exe

That's it! You're all set until framework 5.0! Happy building!

NOTES:

• If your folder location for .net 4.6 csc.exe is different, you'll need to update Program.cs accordingly (they changed the location to the Build folder).
• This technique should work for NT7 as well but I haven't tested.
• If you need to make changes to the application, be very careful. Applications calling csc.exe require the output in a predefined format in order to detect errors and warnings. Make sure you are passing all output from csc.exe and that you don't inadvertently delete the original exes.
• I did just a 64 bit application and placed in the 32 bit folder (only using NT 32 bit ATM). It works for me but YMMV.