-
Notifications
You must be signed in to change notification settings - Fork 15
Information for Developers
This text is supposed to provide an introduction to the source code of this project and possibly also some of its dependencies.
The RiotControl solution was recently split up into three different projects. These are:
- RiotGear: This is the core library on which both RiotControl and RiotShield rely. It contains the code that is common to both of these projects.
- RiotControl: This is the graphical WPF version of the service that is used by most Windows users.
- RiotShield: This is the command-line version of the service that is being used by most Linux and MacOS users of the software, also the odd Windows user.
I recommendend that you use most of the debug DLLs provided by the standard RiotControl.zip package as references instead of compiling them yourself as this can be rather dreadful work since there are so many dependencies. The only one which you probably do want to compile yourself is the RiotGear.dll. Just create a /References directory in the solution root directory and copy the DLLs that you are not going to build yourself there. RiotControl and RiotGear are already configured to use the x86 debug output of the RiotGear project by default so there's nothing you'd have to change there anyways.
I configured all these solutions to get their referenced DLLs from a /References directory within the repository. This directory isn't part of any of these repositories as it would require committing binaries to a repository. Even the thought makes me shudder with disgust.
Since I develop this software on Windows I actually went through the trouble of creating symlinks for all references in every /References directory of these projects. This way I always get the most recent binaries without polluting the paths specified in the vcproj files. Look up the mklink command to see how it works on Windows. It does use the inverse argument order of ln, though, which is something that always confused me.
As some of you already noticed, I used Visual Studio 2012 to generate some of the solution and project files. This software is currently in a public beta stage but it works fine for me. I was experiencing annoying bugs in Visual Studio 2010 over the past months and had two occasions where it just got randomly corrupted and required a complete reinstallating after purging all its remaining files. This greatly upset me and ultimately prompted me to move on to 2012 permanently.
From what I have seen, the files it produces are actually largely compatible with Visual Studio 2010 and would merely require an alteration of the headers to make it work with that version of Visual Studio - but I might be wrong. People seem to have figured out a way anyways. The only issue is that it can make merging solution files back into the master branch awkward. Perhaps I should edit these files myself just to make this somewhat easier.
I actually reverted the header of the RiotControl.sln file back to the Visual Studio 2010 format... apparently that suffices to make it load the solution again, even though the format is totally identical and compatible otherwise. I suspect that this won't be an issue for now then.
It is a small utility of mine. The script is available in the AssemblyInfo repository and requires Ruby to be installed.
Some people already noticed that I recently added a new pre-build step in most of our Visual Studio projects. For me, it refers to a "generateAssemblyInfo.cmd" in a directory referenced by the %PATH% variable which basically just runs something like ruby X:\Path\To\generateAssemblyInfo.rb. This isn't necessary to build any of the projects and you can basically remove it, although I insist on keeping this step in the master branch project files. You just have to rename the Properties/AssemblyInfo.template.cs to Properties/AssemblyInfo.cs then if you aren't going to use this tool.
Actually not using this would prevent you from using the regular centralised JavaScript file right now, though, because it checks the assembly info revision sent by the client to the server and will refuse to serve clients whose version is "too old". If you're not using this tool it will default to a revision number of 0 which equals "super old".
So, what is this tool? It is a cheap trick I came up with to achieve automatic MSIL binary version information from a git repository. It counts the number of commits to the active branch and then uses this number as the revision number in the DLL/EXE file that is produced by Visual Studio. This enables me to easily cross-reference the RiotControl versions used by people in the wild with the repository history. git hashes are just not convenient for that, as you might imagine.
The "r243" kind of version information that you might have seen in the title of the RiotControl WPF application is the result of this tool.
I suppose I could make a C# version of this application and distribute it as an EXE to make the lives of the developers easier as most of them were upset that I expected them to install Ruby. Well, suck it up! Typical open source project hurdles.