[2.0] Workbench Scripts.WB.dll for faster compile times.
I recently started a thread in Modification Suggestions about an idea i had for reducing the amount of time it takes the server to compile.
You can find this thread at:
http://www.runuo.com/forums/showthread.php?t=72115
This is mostly aimed at people like me that restart the server very, very often and get annoyed that the server has to recompile every script, not just the script i changed.
You can find my additions in the attached file as:
and
The original idea was for a new folder that compiles like the \Scripts folder does and created a separate assembly, but....
After looking at the code in ScriptCompiler.cs closely, i realized that it would be much simpiler to add in a new file extention and have it generate an assembly for the new extention like it already does for vb and cs files.
Note: This mod is for c# code only.
I don't use visual basic, so i didn't include a vb compiler version...
If you don't know how to compile a new Server.exe, check out Penndragon's faq here:
http://www.runuo.com/forums/showthread.php?t=70781
Once you have the Server.exe built with the ScriptCompiler.cs i include here, using the mod works like this:
1.
Any c# script file that ends in .wb (short for Workbench) will be compiled into a Scripts.WB.dll
This allows you to edit your .wb files as often as you like and not have to re-compile the .cs scripts each time.
If you only change a .wb file, the server will only compile the .wb and will load the .cs cache.
3.
After you are done, just rename your script file back to .cs!
( If you use this mod, Please, please rename files back to .cs. I can hear the questions about .wb files now... )
Test server version of RunUO 2.0 anyone?
Edit:
Currently, if a script contains a class or method that is required to exist by another file, you cannot just rename the cs to a wb.
This is because when you start the server, the cs scripts are compiled together and they have to all work together.
I am working on the problem but until i can find a solution, there does exist two partial workarounds for this situation.
1.
Make the rest of the dependant files wb.
This is a partial solution because having too many files to keep track of sucks.
2.
Copy the existing cs you want to edit and name the extention of the copy wb.
This way, the original cs script exists for the other scripts that depend on it, and you have a copy that you can make changes in.
This workaround is limited in that you can only check to see if your changes will compile.
Your changes to the wb file will not appear in-game since the dependant files compiled against the cs version of the file in question.
This is a partial solution because it does not work in all cases.
An example is that this workaround works on BaseKnife, but not on BaseWeapon.
I recently started a thread in Modification Suggestions about an idea i had for reducing the amount of time it takes the server to compile.
You can find this thread at:
http://www.runuo.com/forums/showthread.php?t=72115
This is mostly aimed at people like me that restart the server very, very often and get annoyed that the server has to recompile every script, not just the script i changed.
RunUO - [www.runuo.com] Version 2.0, Build 2401.3936
Core: Running on .NET Framework Version 2.0.50727
Scripts: Compiling C# scripts...done (0 errors, 0 warnings)
Scripts: Compiling VB.NET scripts...no files found.
Scripts: Compiling Workbench C# scripts...no files found.
Scripts: Verifying...done (2086 items, 497 mobiles)
To do this, i made two additions to ScriptCompiler.cs (SVN version 66).RunUO - [www.runuo.com] Version 2.0, Build 2401.3936
Core: Running on .NET Framework Version 2.0.50727
Scripts: Compiling C# scripts...done (cached)
Scripts: Compiling VB.NET scripts...no files found.
Scripts: Compiling Workbench C# scripts...done (0 errors, 0 warnings)
Scripts: Verifying...done (2087 items, 497 mobiles)
You can find my additions in the attached file as:
Code:
#region Workbench Mod 1 of 2
Code:
#region Workbench Mod 2 of 2
After looking at the code in ScriptCompiler.cs closely, i realized that it would be much simpiler to add in a new file extention and have it generate an assembly for the new extention like it already does for vb and cs files.
Note: This mod is for c# code only.
I don't use visual basic, so i didn't include a vb compiler version...
If you don't know how to compile a new Server.exe, check out Penndragon's faq here:
http://www.runuo.com/forums/showthread.php?t=70781
Once you have the Server.exe built with the ScriptCompiler.cs i include here, using the mod works like this:
1.
Any c# script file that ends in .wb (short for Workbench) will be compiled into a Scripts.WB.dll
This allows you to edit your .wb files as often as you like and not have to re-compile the .cs scripts each time.
If you only change a .wb file, the server will only compile the .wb and will load the .cs cache.
3.
After you are done, just rename your script file back to .cs!
( If you use this mod, Please, please rename files back to .cs. I can hear the questions about .wb files now... )
Test server version of RunUO 2.0 anyone?
Edit:
Currently, if a script contains a class or method that is required to exist by another file, you cannot just rename the cs to a wb.
This is because when you start the server, the cs scripts are compiled together and they have to all work together.
I am working on the problem but until i can find a solution, there does exist two partial workarounds for this situation.
1.
Make the rest of the dependant files wb.
This is a partial solution because having too many files to keep track of sucks.
2.
Copy the existing cs you want to edit and name the extention of the copy wb.
This way, the original cs script exists for the other scripts that depend on it, and you have a copy that you can make changes in.
This workaround is limited in that you can only check to see if your changes will compile.
Your changes to the wb file will not appear in-game since the dependant files compiled against the cs version of the file in question.
This is a partial solution because it does not work in all cases.
An example is that this workaround works on BaseKnife, but not on BaseWeapon.