Over the past few weeks I’ve been working on a new project in our company which involved building a number of inter-dependent assemblies, “strongly naming” them and installing them into the Global Assembly Cache. Over the course of the project, I was forced to look at a number of issues related to assembly versions, solution organisation and the deployment of assesmblies in a developer environment.
So given that it’s been a while since I wrote anything vaguely technical, I thought I’d document some of these issues down.
What version numbering strategy should we use?
How will we organise our Solution to make this easily manageable?
How will we manage these libraries during the deployment phase?
How will we circulate stable versions to developers during on-going development of other projects?
Alas, all my hope & dreams & promises of a regular blog post, dashed… oh well, here’s one now.
I’ve been playing with the System.Threading.Tasks namespace over the last few hours and it’s quite neat.
We’ll be rolling out some new software in the next few months at work which Processes SMS messages from Customers. In the past we had fudged together our own Multi-Threading/Multi-Pipeline code to try and get messages through the system as quickly as possible but it was fairly bloated to say the least. Enter the new Task and Parallel classes in .NET 4.0
Necessity is the mother of all… reasons to learn something new. So when some project requirements came down to put together a Search UI for an object graph of ~200 different properties in one wide table, we got an opportunity to play with some dynamic LINQ. We needed to come up with a quick way to allow a user to search across all the properties without making the UI unwieldy. What we provided them with was a simple UI allowing the user to apply 0:N conjunctive search filters. For each filter they choose an object property to filter by, the filtering operator (equal, less than, etc…) and the value they were searching for.
By the way, if there’s a nicer way to do this, I’d love to know about it.
I was trying to get my Development Environment up & running the other day with Silverlight 4. It turns out that the Silverlight debug runtime isn’t actually part of the standard client, or the Silverlight 4 Tools for Visual Studio.
The “Silverlight managed debugging package” is part of the developer runtime, not the SDK or Tools. Make sure you have the latest version of the developer runtime installed (available at http://go.microsoft.com/fwlink/?LinkID=188039
On the plus side I did throw together this nice pretty clock just to test everything out.
There’s probably a dozen ways to break this, but it covers the basic for autosizing the grid, limiting the dimensiosn with min height & max height sections, drawing lines & drawing ellipses & a small bit of math.
We had a situation in work where we needed to make service installation a more configurable process.
So a very simple example, In order to install a .NET Windows Service we need to provide it with a username & password that the services will run as. We can either provide that information at installation time, or through the following properties in the ProjectInstaller.cs file for your service.
However in an environment where multiple developers are working on a service, particularly a service that requires elevated privileges and needs to run as a specific account, this can be a royal pain.