Showing posts with label Visual Studio. Show all posts
Showing posts with label Visual Studio. Show all posts

Friday, December 16, 2011

Code generation in C#

I wrote my first code generator on the weekend. The real work - generating the C# class files - was trivial. Getting the generator into a state so that it could be easily used was more difficult.

There are a few ways you could do code generation in .NET. I explored:
I went with T4 Templates. They were a little obscure at first but provided the easiest entry point into using the code generator. You just build-up your source file and then right-click and select "Run Custom Tool" on the .tt file to generate the code.

I encounted a few issues when trying to write my template. They were:
  • Extension methods can't be embedded into a T4 Template. There is a workaround. I ended up converting my extension methods into normal methods (I only had two).
  • Accessing your assemblies is difficult in Visual Studio 2010. It has been explained very well. I managed to access my assemblies by writing something like <#@ assembly name="$(SolutionDir)..\DomainEntities\bin\Debug\Cpa.DomainEntities.dll" #>
The example T4 Templates I found on the Internet were a little more complex than what I wanted. (Examples should be as simple as possible.) I wanted to load a source file into memory and generate class files from that. Download my example template if you want something similar. It loads in a CSV file that has two columns (first column is the name of the class, second column the name of the property) and generates some puesdo-code of what the class files will eventually look like. I used this as my base template, then expanded it to create proper C# class files.




Friday, July 15, 2011

Tools for learning F#

Every few months I try to learn me some more F#. It isn’t easy.

I stumbled across a nice learning tool by Chris Marinos. It works on the premise that you learn by making the unit tests pass (initially, they all fail). It's a nice idea. The only issue is that the testing framework it uses was written in NUnit. I don't use NUnit anymore. With a couple of little changes I switched it to Microsoft's unit testing framework. You can get my version here.

There is also http://www.tryfsharp.org/. It gives a good intro to F# that you can do online (don't need Visual Studio or nothink).

I tried to do some interoperability between C# and F#. When testing an F# console app in a C# test project, my functions didn't return results. I changed my F# console app to a F# library and it worked correctly. (Don't know why C# can't use an F# console app.)

Tuesday, June 28, 2011

Computer Opponent: Noughts & Crosses

The next task on my list for making a strategy game is writing a computer opponent. In the tutorial I describe how I’ve used variations on the minimax algorithm to play noughts and crosses (tic-tac-toe). I chose noughts and crosses because it’s finite (always ends in 5-9 moves) and simple, yet there are thousands of different solutions. Eventually, I plan on using a minimax type algorithm for a game which will use the hex board tutorial I created in Unity earlier.

The C# source code for this project is available here.
The tutorial is available here.

The end result of this project is a console application that plays noughts and crosses with itself. It cycles through games using negamax, alpha-beta pruning and negascout. Every game is, of course, a draw. (You may notice that negascout is slower than alpha-beta pruning. This is because I haven’t ordered the search tree, it’s such a simple game that it isn’t worth it.) There is also a test project that runs a number of tests to make sure that the algorithms are doing what I expect them to do.

Wednesday, June 8, 2011

MSI, Orca and file permissions: or it's 2011 and installers still suck

I had to create an MSI for distributing some software. After installing, I noticed that one of the files didn't allow read/write permissions to my application. You'd think that would be easy to fix: just go into Visual Studio, select the file and change the security permissions, right? Wrong.

If you have the same problem, one way to resolve it is:
  1. Download Orca (it allows you to edit MSI files)
  2. Run Orca and open an MSI file
  3. Go to the LockPermissions table
  4. Add a new row and fill in four of the five fields (see image). The fields are:
    1. LockObject (the ID of the file, this is found in the File table);
    2. Table (the name of the table that you're editing, in this case the "File" table, but it could be "Registry" or something else);
    3. Domain (I left this bank);
    4. User (I put in "Everyone" which is incredible insecure, but I really don't care);
    5. Permission (the meaning of the numbers is explained here);
  5. Save the MSI and exit Orca


Usually, installed files take on the permissions of the directory they are installed to. If you install to "C:\Program Files," your files will get the permissions that the program files directory has. However, using LockPermissions will overwrite all of these permissions and just assign SYSTEM and the permissions you added in the LockPermissions table. This is super-dodgy, but then, the whole thing is super-dodgy. Other people recommend using a custom action as part of the installation, e.g., using "ICacls". This is probably a better way to do it, I was just running out of time.