Here's something interesting that I discovered. I decided to switch my client/server PCs so that the host was running on my Win2003 machine and the client was running on my Win7 machine. It worked! I was able to receive messages across the network. So it's something about Windows 7 or my computer that's causing the problem. But what could it be?

I've created a prototype application which uses WCF and MSMQ to send simple "hello world" messages from a client app to a server app. I was able to get it successfully working on my machine. However, being a client/server technology, I need to get this prototype working across a network. So, I got a second PC, installed MSMQ on it and my client application. When I run the client app on this second PC, it does not work correctly. I don't get any run-time exceptions, however, the messages are not received on my server. If I go into my client PC's Computer Management console, I can see the messages in its outgoing queue. So, it appears that the problem is that my client app is not connecting to my server app. Both machines are on the same domain and can see each other in Windows Explorer. I'm able to copy files back and forth from both PCs. If I execute MessageQueue.GetPrivateQueuesByMachine() on my client PC, I can see my server's queues. I should note that my server's queue is private. I'm using Visual Studio 2008, .NET 3.5. My server machine is running Windows 7. My client PC is running Windows Server 2003 R2. My binding is netMsmqBinding. To create my prototype, I am using Michele Bustamante's QueuedServices example from chapter 6 of her "Learning WCF" book. You can download her example here: http://www.thatindigogirl.com/downloads/LearningWCFVS2008.zip My client side's app config is at the end of this post. If I attempt to bypass WCF and send the message to MSMQ directly...

MessageQueue rmQ = new MessageQueue("FormatName:DIRECT=OS:MyComputerName\\private$\\messagingservicequeue");
rmQ.Send("Hello world");

...I get the same behavior as before. The message is stuck in the client PC's outgoing queue. I'm not sure what's wrong or even where to begin debugging this issue.

<?xml version="1.0" encoding="utf-8" ?>

<configuration>
<system.serviceModel>
<bindings>
<netMsmqBinding>
<binding name="netMsmq" >
<security mode="None" />
</binding>
</netMsmqBinding>
</bindings>
<client>
<endpoint address="net.msmq://MyComputerName/private/MessagingServiceQueue"
binding="netMsmqBinding" bindingConfiguration="netMsmq"
contract="WinClient.localhost.IMessagingService" name="netMsmq" />
</client>
</system.serviceModel>
</configuration>

Actually, I've always hated that inline if syntax. In fact, my version of that routine would be even longer:

private void appendBooleanField( boolean value, boolean lastField )
{
strind field;

if ( value )  
{    
	field = "y";  
}  
else  
{    
	field = "n";  	
}

appendField( field, lastField );  

}

Sorry to revisit an old thread, but I happened to stumble across an article that relates to this topic. According to Microsoft's Design Guidelines for Exceptions: "Do not overuse catch. Exceptions should often be allowed to propagate up the call stack." http://msdn.microsoft.com/en-us/library/ms229005.aspx Of course, this guideline is in reference to .NET code and not SQL, but it's still good advice.

I work for an IT consulting company and one of the clients we are pursuing is using Visual Studio 2008 Team System. I'm kind of new to Team System. I've used Visual Studio for years, but not the Team System. Currently, we do not have any licenses for Team System. In any case, the pursued client is hosting the Foundation Server and we need to purchase licenses for VSTS 2008. I'm really not sure what we need to buy. I'm particularly confused by this concept of a CAL. According to Microsoft's web site, purchasing a VSTS edition automatically includes a CAL: http://msdn.microsoft.com/en-us/vsts2008/products/cc149003.aspx A Microsoft sales representative said that purchasing a VSTS edition includes 5 CALs. A fellow employee claims that we need to purchase an additional CAL per developer (and this is over and above what VSTS includes). So, a few questions: 1) Do we need to purchase additional CALs or is buying a VSTS sufficient? 2) Do we really get 5 CALs per VSTS? 3) If each copy of VSTS we buy includes a CAL, why would anyone need to buy a CAL separately? Also: The Microsoft sales representative recommended that we buy the licenses from a reseller. I went to the resellers page, added 5 copies of VSTS Developer edition, but there was no volume discount. 4) Why would anyone buy VSTS through a reseller if there was no volume discount? 5) Or did I do something wrong? Finally, just to clarify one point. We (meaning my company) will NOT buy or host the Foundation Server. The client we are pursuing already has Foundation Server and we will be connecting to their server. So, we do not need to buy Foundation Server.

You mean RAISERROR is working as expected and the calling code is incorrect, right?

Wait a second! Does this error handling strategy even work? When I execute the following stored procedure, I get an error on the RAISERROR statement. CREATE PROCEDURE dbo.spErrorHandlingTest1 AS BEGIN DECLARE @Error INT DECLARE @myInt INT SELECT @myInt = 1/0 SELECT @Error = @@ERROR IF @Error > 0 GOTO EH RETURN 0 EH: RAISERROR(@Error, 16, 1) RETURN @Error END Msg 8134, Level 16, State 1, Procedure spErrorHandlingTest1, Line 8 Divide by zero error encountered. Msg 2732, Level 16, State 1, Procedure spErrorHandlingTest1, Line 16 Error number 8134 is invalid. The number must be from 13000 through 2147483647 and it cannot be 50000.

Well, that means that time (measured as start of project to end) is quicker but time (measured in man-hours) is longer. Correct?

Don't you do a round of testing for each new release?

Sure, I believe in standards too. In fact, my standards that I used on the last project are actually more strict. But unless someone can come up with a valid justification, this particular standard is a bad one.

We just heard back from the client that we don't need to support Safari. Only support for IE6+ and Firefox 3 is required.

A lot of stored procedures are simple, one-statement CRUD operations that probably don't require error handling, which is why I think that mandating that every single sproc have an error handler is excessive. These coding standards are brand new. If we get the contract, this will be the very first project to use them. So, consistency with existing applications is not an issue.

> If you get an error you can enhance the message to help track down the problem What sort of information would you include to enhance the error message? For example, what would you change about this stored procedure? --air code CREATE PROCEDURE GetCustomerCount AS SELECT COUNT(*) FROM CUSTOMERS RETURN 0 EH: RAISERROR(@Error, 16, 1) RETURN @Error

Yes, I understand that it proports to produce better code. But I'm not really asking about code quality. I'm asking about project estimation. EDIT: Also, note that this is not a true agile approach. There won't be pair programming for example. The two agile tennants they want to use are interative releases and stand-up meetings. That's it. The business rules for the entire scope of the project are already done.

I'm used to doing waterfall design and development. For my next project, we're going use agile methodology. Well, it's not really agile. The only part of agile they want us to do is to do iterative releases and have daily stand-up meetings. I estimated the project to be 1,900 hours if we use waterful (which we won't, but I did it waterful because that's what I'm use to). Now, I want to convert that waterfall estimate into an agile estimate. Is there any rule of thumb or simple formula I can use? I'm thinking that agile should take longer because of the iterative releases, in that every release requires a new round of testing and deployments. Any thoughts?

One of our clients has just developed a set of coding standards for their .NET and SQL Server application development. For the SQL Server standards, they say the following regarding error handling: -----------start of quote--------------- Error Handling - Should be used in every stored procedure, with an Error Handling section at the bottom of the procedure - Stored procedures should return the success or failure of the stored procedure by returning 0 (zero) upon success, or return the error number upon error. - @@ERROR should be checked after Every INSERT or UPDATE to deterimine the success or failure of that action. - @@ROWCOUNT should be checked after every INSERT or UPDATE if at least one or more records were expected to be affected. DECLARE @Error int, @RowCount int T-SQL here RETURN 0 EH: RAISERROR(@Error, 16, 1) RETURN @Error -----------end of quote--------------- Does this sound like a good idea? Having an error handler in every stored procedure seems excessive. Honestly, I'm of the opinion that error handling for the sake of error handling is a waste of time and only serves to obsficate your code. The only reason why you should handle an error is if you're going to do something meaningful with the exception. For example, you know what the error is and how to fix it. Or maybe you want to log it to the database. Or you need to rollback a transaction. But if all you're going to do is catch it and raise it up the call stack, that's pointless code because the error will bubble up the callstack anyway. Do you agree or disagree? Why or why not?

One of our clients wants us to create a web application that is compatible with Internet Explorer 6+, Firefox 2+ and possibly Safari. They want us to use ASP.NET 3.x and Ajax. I've been developing Web apps for the past few years but for only IE. My question is how difficult is this to achieve? How much overhead does this add to a project's life cycle?

Hi Dave, Thanks. Well, if you or anyone else can thing of something that I missed let me know. The Upgrade Wizard and Upgrade Companion don't do enough to make the source code more .NET-like, such as renaming variables prefixed with "lng" to "int". In VB6, it was common to prefix your variables with an abreviation to indicate data type. For example: Dim intNumber1 As Integer Dim lngNumber1 As Long In .NET, an integer is now called a short and a long is now called an integer. So the tool will upgrade that code to: Dim intNumber1 As Short Dim lngNumber1 As Integer The problem with that code is that the prefix no longer matches the data type. It should be: Dim shoNumber1 As Short Dim lngNumber1 As Integer And actually, Microsoft recommends against using Hungarian notation so it really should be: Dim number1 As Short Dim number1 As Integer The UW and VBUC do not handle changes like this. I can't be the first developer who's faced this problem. I figure that someone somewhere has already written some sort of utility or script that handles changes like this. I don't want to reinvent the wheel if I don't have to.

I'm finalizing a proposal for a potential client who wants to upgrade their VB6 application to .NET. I hate to reinvent the wheel, so I'm wondering what tools or scripts exist to automate the conversion process. I am aware of: Microsoft's Code Advisor Aivosto's Project Analyzer Microsoft's Upgrade Wizard Artinsoft's Upgrade Companion Code Architects' VB Migration Partner Great Migration's gmBasic Microsoft's VB PowerPacks Microsoft's Interop Forms Toolkit We're planning on using 1, 2 and 4. Are there any other tools, utilities, scripts, etc. to automate the conversion process?

There is no significant performance difference between VB.NET and C#. If you wrote two versions of the same app and one performs better than the other, then the most likely explanation is that you wrote the code differently. I remember an example from way back when from Borland who claimed that Delphi was faster than VB and provided a benchmark that 'proved' it. But when you actually look at the code, they were comparing integer operations with floating point operations. Of course, integer operations are faster than floating point operations. Whether knowingly or unknowingly, their benchmark test was invalid. Post your code here and I'll tell you what you're doing differently.