Friday, 8 June 2012

Testing...

Just checking if this blogger app works...

Sunday, 3 June 2012

How to Stop .Net 4 Client Profile being The Default in Visual Studio and Cocking Everything Up

The .Net 4 Client Profile project target in Visual Studio happens to be, about every couple of weeks or so, the bane of my fucking life. I will make a project, forgetting that it is the default for some of the templates and proceed to spend ten minutes wondering why the hell I can't find any references. This annoys the hell out of me and I have not found a way to back out of it being installed as a default for many types of project (listed on this msdn page)

At the behest of a work mate, I'm going to write this short guide on how to change the default for these projects.

In this example, I am going to change the default project target for the Console Application project type.

1. Find the right folder

I don't know where you have Visual Studio installed, but mine is at "C:\Program Files (x86)\Microsoft Visual Studio 10.0"

Further, you need to find where it keeps the project templates.

Should be in: {visual studio directory}\Common7\IDE\ProjectTemplates\CSharp\Windows\1033 (where 1033 is your language region)

2. Open up the archive ConsoleApplication.zip

Actually, best bet is just to extract it somewhere

3. Edit the file "consoleapplication.csproj"

Here we go. In the top PropertyGroup section. Here's the bastard to remove:

  $if$ ($targetframeworkversion$ >= 4.0)
    <TargetFrameworkProfile>Client</TargetFrameworkProfile>
  $endif$

Scrub that motherfucker like it ain't no thang.

4. Save, replace in archive, etc, etc

...

5. Wondering why this didn't work?

Because of reasons that I cannot fathom, there is a cache of the project templates.

6. Copy the files into the cache

They will need to go into a folder called "ConsoleApplication.zip", which will be found at: {visual studio directory}\Common7\IDE\ProjectTemplatesCache\CSharp\Windows\1033

7. DONE

There... Hopefully that feels better. Thanks for wasting my time, Microsoft.

Thursday, 24 May 2012

Projects, Mono, old habits...

I checked out Mono on Ubuntu yesterday and I'm massively impressed so far. It picked up an old .net application that I wrote to publish RSS articles for the Dirty Fire Project website and it worked flawlessly. I think it will be perfect for the side project that I'm working on with an old friend. More on that some other time...

And on suggestion from a new acquaintance, I spent a while getting back in touch with my bass... I hate being rusty and just playing again is so good. More!

Work is interesting. The new tracking cookie legislation in the UK is hitting us hard but it looks like we have a working management solution now. Testing tomorrow, so fingers crossed. I believe we aren't under pressure to release anything until next week so we can test it all tomorrow as required, get it signed off without a rush and then prep the second deployment head in relative calm. Let's hope it works! And, you know, doesn't destroy our billing system, campaign traffic partners, database... o.O

And it's too hot to sleep.

EDIT: Blogger for Android is literally the worst fucking user experience ever. I've been trying to get the Dirty Fire Project website link right now for 30 minutes. Even when I went to the website desktop version from my phone to fix it, the cursor doesn't work properly. The Android app can't even get the right time and date for posts so they appear completely out of order. What a barrel of shite.

Tuesday, 28 February 2012

Spring woes

This blog: http://onlytalkingsense.wordpress.com/2006/06/06/springnet-and-generics/ ... just saved me a tonne of pain. Although admittedly this was after suffering about 2 hours of pain at the hands of Spring.Net completely failing to work all of a sudden.

I'd just re-factored some caching code out of an application-specific project and into a general support library. The caching system is set up in Spring.Net and uses generics syntax to define a cache (which is HashSet based) of an application entity object. This was fine before I re-factored because both the cache and the entity object were in the same assembly. However, after the re-factoring, Spring was completely unable to initialise the caches and saying that it couldn't find the type.

The blog explains that if you are using the generics syntax to define an object which consists of objects that are from a different assembly, then it is not sufficient to use the long-hand qualification syntax. You need instead to create a typeAlias entry for each of those objects from outside of the generic's assembly.

So I was expecting the following to work:

<object id="ThisDoesntWork"
type="Asura.Storage.Caching.Cache&lt;PPT.Entities.Contact, PPT.Entities>, Asura.Storage">
</object>

But instead I had to add this to the config sections:

<section name="typeAliases" type="Spring.Context.Support.TypeAliasesSectionHandler, Spring.Core"/>

And then this to the spring section:

<typeAliases>
<alias name="Contact" type="PPT.Entities.Contact, PPT.Entities" />
</typeAliases>

And then the object itself looks like this:

<object id="ThisDoesWork" type="Asura.Storage.Caching.Cache&lt;Contact>, Asura.Storage">
</object>

Anyway, see http://onlytalkingsense.wordpress.com/2006/06/06/springnet-and-generics/ for the full article.

Saturday, 25 February 2012

GiveCamp project continuing...

So I'm having a cheap Friday night by staying in and doing some more coding on the project that was started at #GiveCampUK back in October. We've pretty much decided on the database schema now which has meant that I can spend time setting up the entities and support libraries for the application.

Originally, this was going to be an application written using Microsoft Lightswitch, a simple query screen development platform sitting on top of Entity Framework 4. However this was canned due to limitations in Lightswitch preventing us writing queries that would perform well. It's a nice idea and environment (once you've got your head around it), but it's profoundly limiting with respect to what it allows you to do with the queries it generates. So, as I said this was canned after it became clear that it wasn't going to play nicely.

Therefore, I find myself writing a .Net WinForms application. But I've hit a problem which may see this just go back to being a website.

I've put a lot of effort into the model and store patterns used, into the caching that will be available to the application, into the Spring.Net implementation which keeps the whole thing easy to configure, into the stored procedures performing basic data access to the entity tables; but it's no good:

The problem is that this will be used by more than one person, at the same time.

Therefore, if something changes in the database, every connected application must be kept up to date.

This causes me a massive, massive problem for consistency. But I don't know if I am worrying about this unduly? After all, the people using this aren't going to be doing break-neck speed data entry, they aren't going to be removing large swathes of the database, they're probably going to be doing one thing each, and they're probably going to be in the same room. So, how much do I worry about it?

What I have currently is a watchdog system. A scheduled background task in the application calls 'home' to the database to determine if there has been a change since the last time it checked / a change occurred. This notifies the master cache that it should reload its data again. The application needs to make sure that this behaviour does not interfere with what the user is doing too much, and I don't know at this point whether it will do that.

I'm going to try and press in with this as a simple WinForms application, but it is very tempting to just make it an ASP.Net website which means that all the locking can be performed locally and safely.

Maybe I should've gone to the pub after all...

Tuesday, 17 January 2012

Deployment...

Checklists. Tea. Tense. Putting a Spring.Net - based job processor live today which will run tings seen and unseen.



Edit:

Deployed :)


Monday, 16 January 2012

Problem on site...

Problems today on the site as the Logging database filled... That was fun. The whole site started hitting 5.5 second delays as every logging write would cause the database to automatically grow. Interestingly, it happened exactly a month ago as well (massively blaming DBAs).

Just making a note of it here so I can look it up next time :)