Showing posts with label C#. Show all posts
Showing posts with label C#. Show all posts

Tuesday, August 5

ProtoBuf in Unity3D

Recently I needed to add two way communication to Unity3D plugin I worked on. We decide to use plain-old-sockets and use Protocol Buffers to serialize and deserialize the messages.
We already had the proto file that define the messages and the server side is already written so all I needed was ProtoBuf implementation for .NET. The main problem is that most C# libraries for ProtoBuf either use attributes and not proto files or they use reflection which is not supported in Ahead-Of-Time (AOT) environment like Unity3D on iOS.

After some research I decide to use ProtoBuf C# Code Generator project by Peter Hultqvist. The main difference between this and other ProtoBuf implementations is that this one create C# code that does not use reflection and does not depend on binary libraries. It generate 3 files:

  1. The clean messages file that contain only the properties of each message
  2. The somewhat messy serialization/deserialization counterpart of each message.
  3. Helper classes
I use this library on Mac OS X with mono and it run without a problem. It generate clean code that you can easily read.

The few minor issues I did find were quickly (2 hours) fixed by Peter.

Things to note

Api Compatibility Level

One important notice for Unity3D developers: because the current generated code uses InvalidDataException which is not part of .NET 2.0 subset. If you don't to the following change the project will fail when building iOS XCode project with error message that not explain what is wrong.
You must do the following before exporting to iOS XCode project:
  1. Open Build Settings window
  2. Select iOS
  3. Click Player Settings... button
  4. Under Optimization section change Api Compatibility Level to .NET 2.0

Reading Message

If you want to read message from a socket you will need to wrap your Socket instance with NetworkStream and then wrap that with SilentOrbit.ProtocolBuffers.StreamRead. This might be confusing because there is already StreamReader class in .NET, I point that to Peter and I'm sure he will find other name.
If you don't wrap your NetworkStream with StreamRead you'll find that the underlying code uses Position property which is off course not available in NetworkStream.

Using Socket in Unity3D without Pro License

Recently I needed to add to our Unity3D plugin the ability to talk to another application via sockets. I'm a long time .NET developer and sockets is peace of cake to use. The problem start when I test the application on iPad device. During the building of XCode project from Unity I got the exception:

Error building Player: SystemException: System.Net.Sockets are supported only on Unity iOS Pro. Referenced from assembly 'Assembly-CSharp'.

As it turns out Unity3D AOT compiler check and fail if any of your script or the plugins you have uses System.Net.Sockets namespace without having pro license.

The solution is to use a plugin call Good Old Sockets which you can find right in the Assets Store of Unity3D. This library require only to change the namespace you are using from System.Net.Sockets to LostPolygon.System.Net.Sockets. The price is 25$ at this time and their license is very open, you can use and distribute this library without extra cost.

I had very quick response for support from LostPolygon both in mail and in Skype.

Wednesday, June 26

Portable Class Library on Jenkins CI

Like any good developer I try to keep projects organized. Today we finish the first release of our globalization library which we put in a Portable Class Library (PCL) so it will be easy to use it in different projects.

When Jenkins pull the work and start to build it it compline about build errors we did not see on our development machines.

The first error was error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\Portable\v4.0\Microsoft.Portable.CSharp.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.

We did not install Visual Studio on our Jenkins server so the same way I handle previous problems with target fiels I start by simply copy the target files from my development machine to Jenkins.
This didn't solve the problem just led me to the next problem: error CS0234: The type or namespace name 'Linq' does not exist in the namespace 'System' (are you missing an assembly reference?)

Little digging in the on the web and I found that this time Microsoft make our life easy and have a tool to install PCL tools on build machines.

Cross-Platform Development with the .NET Framework is the title of the document inside the MSDN website. There you can read all about cross-platform development for .NET and specifically download the Portable Library Tools and install it with the switch /buildmachine

There you go, PCL on your Jenkins Build machine made easy.

Thursday, June 16

Interval Tree C# implementation

Today I'm happy to publish my Interval Tree C# implementation in CodePlex community code site.
I need to store lots of temporal data in a project I'm working on and to retrieve the data very very fast. After some search on the web I've found article in Wikipedia about Interval Tree which explain the data structure but did not direct me to any implementation of it.
I've also found a C# implementation of Multi-Dimensional Range Search Tree which is very useful for selecting points on two dimensions but did not solve the problem I need.

Finally I've found a Java implementation of Interval Tree which is just the thing I needed. Convert the Java code into C# was no brainer.

I've add some abilities to the implementation like using generics for both temporal value and user data type so you can create interval tree that use int, float, DateTime or even Vector as measure unit. Any struct that implementation IComparable will work just fine.

Also I've add the ability to stub the interval tree in different modes like all interval that contains the point, or contains or exactly at the start. This was important to me to be able to get information out of the interval tree for the actual project.

Like the guy who publish the Java implementation said I need that data structure and I'm publish it to help anyone else need of it.

Hope it will be useful to you as it is to me.

Friday, April 29

Per Developer App.Config

We are working on C# project which use app.config to configure the way our application works.
Since we are using shared source control system we notice we each step on each others those when it comes to changes of the app.config. Each developer change things like the address of some service, which modules to load, etc.
One possible way is to make sure you are not checking-in your modified app.config, but that tedious.

We wanted to have the normal app.config with some reasonable default settings and have per developer app.config file like app_ido.config which will be used if present.

After reading Microsoft.Common.targets for a while I've found target called PrepareForBuild. I've notice that Microsoft were kind enough to use property called AppConfig if you define it. If you do not define it they try to find file called app.config which has build action of either None or Content (in that order).

So, I've create a new Console application, add to it app.config file and put some appSettings in it just to be able to tell which app.config I am using. I've then open the csproj file for edit and add new element inside the first PropertyGroup element called AppConfig and set it to 123. When I've compile it I've got an error that Application Configuration file "123" is invalid and could not be found. That was the way, the rest was easy.

I've change that property element to this:
<AppConfig Condition="Exists('App_$(USERNAME).config')">App_$(USERNAME).configAppConfig>


This did exactly what we needed. We chose to use the current Windows username as our variable to identify each developer. If file with the name of the developer is found - we use it, otherwise we fallback to normal app.config.

There was only one question open which is should we keep the developers app.config files in the source control system or not?

After some thinking we decide not to check them into the source control because those files are dispensable and can only cause harm like merge conflicts.

I hope this will help other developers looking for this behaviour.

You can download sample application, just change the file called app_Ido.config from Ido to your name and your good to go. Remember to rebuild the project after you the file name to see the effect.

Saturday, October 28

Gantt - The current project

Hello,
As a starter for my blog I am going to share with you my up-coming task of architect and develope a gantt system using C#, .NET 2.0, WCF and hopefully WPF. I am a team-member and there are other great people working on this task.

Background

Gantt is a way to communicate progress of task between managers and workers.
The system will be much like Microsoft Project. The reason we are not going to use Microsoft Project is because our business model is much different and we have a lot of security issues like permissions to see activity, permission to report activity times and so on.

The Architecture

We are using a 3-tier architecture to develope our application. It means we have a database, middle-tier and presentation layer. We prefer to do most of the calculations in the middle-tier and send to the client a clean read-to-use objects (or tables).
On the client we get the object model and we present it to the client, allowing it to examine it and to act on it.
Our previous version of this application was written in C++ and use GDI for drawing. This off course lead to pretty dull interface in which alpha-blend is the most exiting feature.
In this version of the application I hope we will use WPF because it suppose to make our life much easier. As someone said, the same way .NET make memory management "Managed" WPF will make graphics "Managed". It means we will create the seine which needs to be display and the WPF engine will display it, no OnPaint and WM_PAINT any more.

To be continued...

As the project will progress I will keep posting with news.