Doesn't require UAC to be enabled either!
Go Fetch!
I was sifting through the hundreds of spammers that have left comments on my blog pointing me in the direction of certain... 'enhancing' medical products and as I pushed "delete all" I noticed that there was actually a legitimate comment in there! Unfortunately I pushed delete on the comment and it vanished forever into the ether. So I dug back through the email notifications and retrieved it.
Buck Hodges : I'm curious to know what's missing from TFS 2008 Build that would make you choose CC.NET over the CI support we provide
The short answer to that is before we migrated to TFS we were using SourceSafe and were using CC.NET on that. When we migrated over to TFS we left our build server as it was and just re-pointed the source control repository. We've built up a set of scripts to deploy the database, website and workflow engine, and it wasn't deemed important enough to switch build servers.
So it's not really a case of what's missing from TFS 2008 Build, it's that we're not missing anything TFS Build 2008 has to offer! :) (And at the moment, if it aint broke, don't fix it)
Thanks Buck
We make use of continuous integration on the project I'm on at the moment. A summary of Continuous Integration (for purposes of this post) is that there is a dedicated computer set up that is constantly checking out the latest version of the source, compiling it, and running a comprehensive set of unit tests and regression tests against it to make sure that we're not breaking existing functionality.
In addition to this, we also deploy a nightly build to a webserver (with this being a web application) that can be tested manually. If testing on this goes well, that release will make it into a testing environment including having exposure to some end users for constant feedback on the progress of our development. These releases (which I'll incorrectly label "UAT Releases" for the purpose of this post) will sometimes contain bugs that can be fixed quickly with a patch. To do this we create a branch from the release code, merge the change into this branch, build, test and then deploy that release... or so we thought!
Even though we've got Team Foundation Server installed, we're using Cruise Control .NET for our build server. Because of this, the process isn't quite as integrated as it could be. We check out the latest version of the source, build it, run the unit tests, if all those are successful we update the assembly version numbers in Assembly.cs, check that back in and then apply a label with the current build number. Seems like a nice straightfoward thing to do, and it works perfectly for a nightly build. Now some of you out there will have spotted the problem with this... those of you that haven't, it's to do with how long this process takes, and the fact that on a nightly build no one is checking stuff in at that time of day.
Yes, as soon as we started doing these during the day, we found that what we were labelling was in fact slightly different than what we were building (or not so slightly, depending on the size of the checkin). Our major problem here was that our action wasn't atomic. If someone did a checkin between our initial checkout and our labelling, their changes were included in the label. As building and testing the project can take between 30 and 60 mins, this is quite a big window during the day.
Our resolution for this was to label the branch *before* doing the checkout, checking out the label, and deleting the label if the build failed (in essence rolling back our changes). Due to the way TFS handles labels, we could check in Assembly.cs with the updated build number and get it included in the label for if we decide to branch from it to patch it or reproduce issues.
Subversion has a lovely little utility called "Blame" which will show you who modified a line of code and when, so you don't have to trawl through the history or the file looking to see when a line was changed. I've always thought that this was a feature that TFS could do with... until now.
It turns out that TFS already has this, but the guys at Microsoft have given it a rather more subtle label of "Annotate". Click on this and all of a sudden the file gets decorated with who checked in which bits and when! Then you can find out who to blame quite quickly! ;)
I started a series over a week ago about the new language features in C# 3 and the capabilities of version 3.5 of Microsoft's .NET framework. This post is designed to act as an index post so you can see what has been posted and what is yet to come! :)
Extension Methods and Interfaces
Anonymous Methods
Lambda Expressions
Implicitly Typed Variables
Anonymous Types / Object Initialisers
Iterators
(Partial Methods)
Query Methods
LINQ
So I digress a little bit. Anonymous methods were new to C# 2, not C# 3. However, they aren't in common use so I thought I'd go into explaining them here, as they are fundamentally important on our journey of learning LINQ.
So as a developer you're familiar with the concept of methods. Named Logical blocks of code that are grouped together, can take input parameters, do stuff, and return values.
The definition of "Anonymous" (according to Merriam-Webster) is "not named or identified".
So we can see here there's a bit of a conflict... although it's not as difficult as it looks! :)
We go from the following well established piece of code:
...
this.button1.Click += new EventHandler(button1_Click);
}
void button1_Click(object sender, EventArgs e)
{
MessageBox.Show("Test");
}
to our new Anonimised version:
this.button1.Click += delegate
{
MessageBox.Show("Test");
};
It's important to realise here that Anonymous methods are purely syntactical. They still compile down to real methods. In this instance opening up Reflector (amazing tool, no one should be without it) shows that the anonymous method has been (rather imaginatively) named <.ctor>b__0. It's called from the constructor and behaves just like a normal method. They can be useful to keep code close to where it is used (in the example of keeping it near the definition for the button in this case) and also for multithreading purposes:
void StartThread()
{
System.Threading.Thread t1 = new System.Threading.Thread
(delegate()
{
System.Console.Write("Hello, ");
System.Console.WriteLine("World!");
});
t1.Start();
}
The above example prints "Hello World!" asynchronously on the command line
They have more uses, as we'll find out later! :)
---
Extensions methods are a new language feature of C# 2 and require .net 2.0 to function
I'm quite a fan of extension methods. For those of you that don't know, extension methods allow you to extend and add behaviour to classes or interfaces without having to modify the class itself. For example, if you are using strings to store telephone numbers (who isn't? :)) and you want to have some form of validation on them, your best bet is going to be to have a static helper class with a method in it that takes a string, performs the validation and then returns a boolean value. Then whenever you want to call it, it looks something like StaticHelperClass.IsValidPhoneNumber(phoneNumberToCheck);
That is until extension methods came along...
As far as the initial developer is concerned, not much has changed. You still need the static helper class, you still need the static method that takes the string, and you still return the boolean. The only difference is a single keywork: 'this'. Now whenever someone wants to use your method, they can just call phoneNumberToCheck.IsValidPhoneNumber;. So why are they useful? Initially, you can see that they lead to easier to read code, which in turn leads to code that is easier to maintain. They also play a key role as a building block of LINQ (more to come on that later).
This is one of the new features of C# 3, which I'm going to be blogging about over the next few weeks or so, and presented on at the free Black Marble Visual Studio launch event.
---
So, what does this have to do with interfaces? Basically, you can write your static method to take an interface rather than a concrete class, and all of a sudden you've got some code that follows that interface round wherever it goes! Makes code re-use a bit easier if you didn't have much control over the original implementation of the code base, as you can have code that's common to a particular interface in that rather than in an abstract class (eg if you are already inheriting from another class in some uses of the interface). This has a really good chance of being abused though, so be careful when you implement these!
---
Extensions methods are a new language feature of C# 3 but only require .net 2.0 to function
...you heard it here!
Disclaimer: This post has side effects
Voting is now open! I happen to be doing a session (alongside Robert Hogg) on a small and rarely known (but amazingly powerful) technology called Volta that's coming out of Microsoft's labs at the moment. If you want to know more about it then vote for that session and come along to DDS! :)
It's the same talk we're doing at the Irish Web Developer conference, so it's going to be rehearsed to perfection by then! :)
Mat
Part 1
Had a strange unit test a couple of weeks ago. It involved the following code snippet (simplified for the purposes of this blogpost):
1: public class Order
2: { 3: public decimal Cost;
4: public decimal Quantity;
5: public decimal GetTotal()
6: { 7: return Cost * Quantity;
8: }
9: }
10:
11: [TestMethod]
12: public void TestTotalPrice()
13: { 14: Order o = new Order();
15: o.Cost = 10;
16: o.Quantity = 5;
17: Assert.AreEqual(o.GetTotal(), 50);
18: }
The test fails under Visual Studio 2005's unit test system, saying that the values do not match. However, the value passes under Visual Studio 2008's unit test system...
Any Ideas?
Server Error in '/' Application.
is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)
It seems to be a good week to get caught out with technical jiggery pokery! Earlier on in the week I was trying to get one of our ASP.NET projects to load up into IIS 7 and was greeted by the above error message. Win32 Application? It's meant to be a .NET application! It shouldn't care about what kind of processor I've got. I happen to be running 64 bit Vista (until the next re-install, when I'll be going back to 32 bit without any questions asked :P) so all of my .NET applications get JIT compiled to 64 bit. This is also true with ASP.NET applications, which meant IIS complaining about a Win32 application was probably something to do with that.
I had a look around the internet, and found that IIS can be configured to host applications as 32 bit apps rather than 64 bit. This can be found in the screenshot below.
The cause of this error in the first place though was an unmanaged DLL that our application links to. As it's a 32 bit dll, it cannot be called from 64 bit software.
This is a follow on from my post about BizTalk reserved keywords.
I emailed 2sms.com about our BizTalk problem with their service the other day, and 6 days afterwards (not 6 working days, 6 actual days) we had an email response back from them saying the following:
Good morning,
I am writing regarding your support email that you sent last week regarding Microsoft BizTalk. I understand that you have adapted to problem of the name ‘send message’ not being recognized. Just to let you know we have taken your feedback on board and we have added an option for others who have this problem.
On our developers page on the website, when you click on web services, in the service URL, if you change the 1.3 to 1.4, the name has now been changed to ‘sendindividualmessage’ allowing the name to be recognized.
Thank you for your feedback on this, please do not hesitate to contact our support team with any further feedback or queries.
Now if that's not a company worth doing business with I don't know what is!
(Please note that this post does not necessarily represent the views of my employer and all that nonsense, I'm just really impressed that we got a shiny new release of their webservice just for us! :))
...to get you to read the instructions!
In the past, the following error message "the project location is not trusted" has not caused many problems. There's been a little utility called the .NET Framework 2.0 Configuration mmc snap-in (gotta love Microsoft and the names that the marketing department come up with). However, someone made a decision to not include this tool in Vista. It was obviously proving far too useful and having a positive impact on people's productivity, so out it came </rant>
After some careful Googling around the Internet, caspol.exe was found to do a similar job. However I couldn't get it to work. I tried for about 5-10 minutes before eventually asking for help. Was pointed in the direction of the instructions, told I was doing it wrong, and then the problem was solved. How is it that someone who knows nothing about .NET, Code Access Security Policies and the technical differences between XP and Vista can point out that I've not included as many parameters as I needed to at the command line!?
For future reference though, the link is here (and it's a very picky program)!
We've recently started using BizTalk to communicate with an SMS provider on the Internet to allow us to send and receive text messages. While setting this up, we encountered some very random error messages that didn't make sense in the context given.
Error 102: Static member 'CommsRouter.com._2sms.www.SMSService_.SMSService.SendMessage' cannot be accessed with an instance reference; qualify it with a type name instead
Error 103: 'CommsRouter.com._2sms.www.SMSService_.SMSService.SendMessage' is a 'field' but is used like a 'method'
It turns out, after a little bit of searching around the Internet that this seems to be a rare (but thankfully not unique) problem. This was the first (and only) blog post I came across about it, and suggests that it's a problem with BizTalk... surely not? Well Jason, you're not alone in this. It seems that BizTalk uses SendMessage and ReceiveMessage internally to handle some sort of message box stuff, and as they are static methods they conflict with anything else that tries to implement a method with the same name.
So what to do? We have a reference to a webservice within BizTalk that contains a method name that refuses to compile. My first guess comes from a C# developer's background. When you add a reference to a web service what really happens is that a magical tool goes off in the background and generates you a proxy class that implements all of the methods of the webservice and allows you to call it from normal code. Surely a similar thing must happen in Biztalk? Sort of...
The file generated is an odx file (BizTalk Server Orchestration) and is full of XML. However, a quick peek through this revealed that it basically does the same thing. It exposes some method names and shows which webmethods are called behind the scenes. Simply renaming the methods shown to BizTalk was enough to get our solution off the ground.
However, this was a bit of a hack, and wouldn't survive anybody pushing "Update Web Reference" on the webservice, so we found another way round.
It's a bit disappointing really, as it's a relatively simple solution. We made a Class Library (DLL) project and housed the web reference in there, and then wrapped the one call we need (and called it something a bit more descriptive than SendMessage!)
Lesson learned for today though: Don't try and use SendMessage and/or ReceiveMessage in your own orchestrations or custom libraries!
Back on track now, here's a nerdy post for the holidays! :)
You hear about string performance a lot in .NET. People will sit there and add strings together in a loop causing thousands of allocations and garbage collections and gradually bring even the beefiest of servers to a halt. Well this isn't one of those posts. It's been proven countless times that you should use StringBuilder for that, and if you don't believe me you can try it for yourself.
This post is to answer one of my own personal pet peeves, which is how is it best to build a string from a bunch of other strings but not in a loop (for example combining UI elements and data from the application to make information appear in full sentences).
I got some very surprising results as well!
In order to make this test as realistic as possible, I performed 1 million concatenations of 6 strings using the 4 different methods:
String.Concat
string s = string.Concat("A", "B", "C", "D", "E", "F");
String.Format
string s = string.Format("{0}{1}{2}{3}{4}{5}", "A", "B", "C", "D", "E", "F");
StringBuilder
StringBuilder sb = new StringBuilder();
sb.Append("A");
sb.Append("B");
sb.Append("C");
sb.Append("D");
sb.Append("E");
sb.Append("F");
string s = sb.ToString();
Add Operator
string s = "A" + "B" + "C" + "D" + "E" + "F";
Now, we've all heard that adding strings together using the + operator is the biggest sin in the entire world... so observe these results:
Tests run:
Concat took 582 milliseconds
Format took 1505 milliseconds
Builder took 784 milliseconds
Add took 9 milliseconds
9 milliseconds? What? 50 times quicker than the next fastest time? Something can't be right there. So I fired up reflector to have a look at what was going on with the compiled assembly and found some very odd results. The code came out as the following (String.Format and StringBuilder were the same so have been omitted):
String.Concat
string s = "A" + "B" + "C" + "D" + "E" + "F";
Add Operator
string s = "ABCDEF";
Makes sense as to why the add function goes so quickly though, as the compiler optimises out the concatenation and just gives you the resulting string. The interesting part here though is what has happened to string.Concat. The compiler has replaced the call to string.Concat with the add operator, and because one optimisation has already occurred it doesn't then optimise this out into the raw string.
What is also interesting here are the results themselves. Concat was the quickest (closely followed by builder) which means that if you are sticking a bunch of strings together as a one off and not in a loop, String.Concat is the way forwards! Here's the controversial bit though, Concat translates into the + operator, which means for one shot string concatenation, + is actually the fastest way of doing it! Having said that, String.Format contains all sorts of Internationalisation magic and does clever things while formatting numbers and dates (when your concatenating things that aren't strings).
Until next time! :)
More Posts
Next page »