The following are instructions for setting up an environment for CSLA .NET development:
There are a set of environmental things you’ll need to take care of first.
Contributors get subversion and bugtracker credentials. Source code for CSLA .NET is stored using subversion (with TortoiseSvn as the client). Bugtracker.NET is used for bug/task/enhancement tracking.
You will need to set up your machine with the following:
- Visual Studio 2012
- Important: You need to set your global tab size to 2, and choose the option to replace tabs with spaces (no tabs allowed!)
- Silverlight 5 SDK and tools
- WP8 SDK and tools
- Important: You need to open TortoiseSvn’s Settings and set up this as your Global Ignore Pattern string:
- *.o *.lo *.la *.al .libs *.so *.so.0-9* *.a *.pyc *.pyo *.rej *~ #*# .#* .*.swp .DS_Store *.suo *.vbproj.user *.csproj.user *.dbproj.user *.webinfo bin Bin obj _vti_cnf _vti_pvt _vti_script _vti_txt ClientBin Debug Release *.mgx *.mx TestResults Thumbs.db *.resw
Once you have that all installed, and you have your svn credentials, you’ll need to do the following:
- Create a directory called c:\Visual Studio Projects\csla
- In that directory, check out the following from svn
That should get you the framework and unit test code.
As far as coding standards – follow the code style you see in CSLA .NET. Here are some basic guidelines/rules:
- Please make sure to set your Tab stops to 2 and to USE SPACES in VS
- Casing and stuff
- Use _fieldName for all instance fields
- Use ClassName
- Use PropertyName and MethodName
- Use parameterName for parameters
- Only check in code if it builds for.NET, Silverlight, and Windows Phone – csla.silverlight.test.sln and csla.wp.test.sln are good tests to ensure a successful build
- There are multiple people actively working on this code base, so be aware you may need to do an Update before a Commit
- When you do a Commit, there’s a place to enter an issue number – this is a bugtracker issue number, and should correspond to some open issue (task, bug, etc) in the tracker.
- When you start working on an issue change its status to In Progress
- When you complete an issue change its status to Checked In (leave it assigned to you)
- Rocky will mark the issue Closed when the change goes into a release