I asked my colleague and our ASP.NET expert Alex Thissen how I could solve a problem I had for some time. I have a Windows Form application and a ASMX 2.0 project in the same solution. Whenever I start the debugger to step through some code, I have to attach the debugger to the webserver that's running my webservice. This can be quite annoying, when you have to do this dozens of times a day. Alex had the solution, and was surprised I didn't know this already. Fact is however, I asked a lot of people about this in the last few days, but no one knew the answer. So although I'm not the only one to not know this (until now), you might be as surprised as Alex was. ;-)
The solution is to set both the Windows Forms application as the webservice as a startup project. Right-click your solution and you'll be presented with the following menu.
Now click the highlighted option and you'll be presented with a dialog window. In it, you can setup the multiple startup projects, as shown in the image below.
I've added two green arrows to show you exactly the projects I've set as startup projects. Once you close this dialog window, you'll see the solution is now bold, instead of just one project. Now the debugger will automatically attach itself to both projects. It will also launch the default webbrowser however (of course Internet Explorer) which you'll have to turn off. Go to the project property pages of your webservice, and select the "Start options" in the list on the left. You'll be presented with the following options, of which you'll have to set the "Don't open a page", as shown in the image below.
That's it, happy debugging!
Back in the old days, when we all were using Visual Studio.NET 2003, we had this cool tool called CopySourceAsHTML. It was a plugin into Visual Studio with which you can copy source into your wysiwyg editor, so your post will have code-coloring.
Just read that the tool by Colin Coller was retwritten for Visual Studio 2005 by Derick Bailey and Jason Haley has put together an installer for it. Download it here. After installation, in Visual Studio 2005, go to Options, Environment, Addin/Macro security and press the "Add..." button. Then go to the installation folder, confirm, restart Visual Studio, select some code and right-click it.
Happy posting!
/// <summary>
/// Inserts a user
/// </summary>
/// <returns>Returns the primary key value</returns>
private int InsertUser()
{
int identityValue = 0;
using (SqlConnection conn = new SqlConnection())
conn.Open();
// Insert user, get the primary key value
// for the example, we'll set it here:
identityValue = 1;
}
return identityValue;
[Test]
public void InsertUserTest()
int identityValue = -1;
using (TransactionScope scope = new TransactionScope())
identityValue = InsertUser();
Assert.AreNotEqual(-1, identityValue);
public void UpdateUserTest()
int rowsUpdated = 0;
// update user, using the retrieve pk value.
// set rowsUpdated; again, for the example, we'll set it here:
rowsUpdated = 1;
// Do NOT call scope.Complete()
// The transaction will rollback.
Assert.AreEqual(1, rowsUpdated);
If you're using .NET 2.0 together with SQL-Server 2005, you're in for a treat. The TransactionScope. A lot of people have written about it already, and most people are raving about it. Most, because there seem to be some drawbacks about the new System.Transactions namespace. But before I'll start talking about those, let's hear the good parts first. I'll explain what TransactionScope is, for those who might not yet know, and in another post explain the difficulties you might have with it.
The good part is that we can create a transaction extremely easy, and include complete codeblocks. If you take a look at the codeblock below, you can see that we're including the new System.Transactions namespace. And in the InsertUser method, we're starting a TransactionScope. Everything within the brackets { and } can enlist in the transaction. When something goes wrong, the scope.Complete() is skipped and at the closing of the bracket, the transaction is rolled back.
using System.Transactions; public void InsertUser(string userName, string password) { using (TransactionScope scope = new TransactionScope()) { using (SqlConnection conn = new SqlConnection()) { conn.Open(); // do some saving scope.Complete(); } } }
Everything within the TransactionScope, that's handled by a Resource Manager (RM), will be enlisted in the transaction. In our case it's the connection to SQL-Server 2005. And the transaction manager (TM), is in this case, the Lightweight Transaction Manager (LTM). It's a new TM so your transactions don't need the heavy-weight Microsoft Distributed Tranasction Coordinator (MSDTC). This makes your transactions much lighter and faster. But you need to meet certain criteria before this can be true. If not, you'll still need MSDTC for your transactions. The cool part however is, that your transactions are automatically escalated to the MSDTC, without you knowing. It's all happening in the background. This is called promotable enlistment. And at the same time, that's a bad thing. Because when it happens, and you're not expecting it, your transaction will be much slower.
So when will your transactions be promoted to an MSDTC coordinated transaction? When the transaction spreads multiple app domains, two durable RMs show up in the same transactions, or a durable RM is used that does not support single phase notifications. more
This list is courtesy of Sahil Malik, who inspired me to write this blog entry, and the next few. Inspired, because I don't share his opinion on this subject in every way. Also because I had about 15 explorer windows open searching for the right information, of which 10 were different articles on his weblog. I'll explain what the above list means, in the near future. You might want to check out the TransactionScope class yourself.
As said before, we're using Windows Workflow Foundation (WF) to support flexible processes within our application. Read Marc's blog about our experiences.
Anko Duizer already mentioned WF being quite difficult, and he had doubts about the mainstream developers picking up WF, as Microsoft expects. But I didn't expect it to be so difficult. The fact that we don't have a lot of documentation and even less support, probably influences our judgement on the product. But it's also pretty complex when you consider you need a lot of activities, with underlying activities and even more code-behind with a lot of events. And then we're not even talking about persisting state, getting it back and having completely new architectural issues. Simple things like getting all objects in a certain state raise a lot of questions and/or issues.
And looking through release notes you notice that they've build a lot of things that were requested after beta 1. That might seem nice, but it doesn't give me much confidence that they've build WF based on experience of what's exactly needed in such a product. I think they've still got a long way to go. And as far as I can tell, this should be released together with Vista and Office 12. Pretty hard deadlines for all teams, which in my opinion can only result in pushing the date backwards.