Dot Net Tips and Tricks

VS 2008 and the accompaning c# 3.0 has virtually changed the way I write code. I know that’s a lot to say about a product, but I feel that strongly about it. It has simplified my writing by exciting me to go back and look at how I write code.

I’ll start with Lambda Expressions because they have made the most difference in my code. For those who need a starter course, a good article on them is here. What I love about them is ability to create action functions with them. An example would be the following:

_listofWidgits.ForEach(t =>

{

//Do something to each widgit.

}

No defining some method, just do it. Another alternative would be to define a method that takes a widgit as the only parameter and phrase it as follows:

_listofWidgits.ForEach(SomeMethod); //No need to spell out the fact that you are passing a widgit to the method. Intellisense does it for you.

How’s that for shortening your code. Anyway, I’ll talk more about LINQ and c# 3.o soon.

Well it’s finally here. We’ve all been waiting for the final version and the wait is over. We have already converted our applications to the .Net 3.5 framework and the conversion was completely painless. No conflicts whatsoever. The 3.5 framework still uses the .Net 2.0 runtime, so the conversion should happen without major problems if coming from a 2.0 or 3.0 codebase.

I’ll update more as the weeks progress on the new features and our experiences with them.

Garick

A short note on this issue that I came across recently. Let’s say we are trying to debug a managed/unmanaged code in Visual Studio 2008 in a 64-bit machine. We complete the code and hit F5 (debug the application), and land up with the following error:

Error while trying to run project: Unable to start debugging.

The components for the 64-bit debugger are not registered. Please repair your Visual Studio 2008 Remote Debugger installation via ‘Add or Remove Programs’ in Control Panel.

Okay all that we are doing is debugging an application in the local machine. So why should there be a problem with the remote debugger installation? Here is some background on how debugging works in 64-bit environment that explains why you see this error message.

Even on a 64-bit machine, Visual Studio runs as a 32-bit application. This means that Visual Studio would run in the Windows-on-Windows (WoW64) layer. It would not be possible to attach a 32-bit debugger to a 64-bit process. However, if you want to debug a 64-bit application, there is something special that Visual Studio does to make this possible. We would achieve this pseudo-remotely. You are running the debugger on the same machine as the process but debugging is done through the remote debugger. All this happens behind the scenes and you as a developer would not need to do anything special.

Now, if you are seeing this error on a 64-bit machine, I would assume that the remote debugging components were not included during the Visual Studio installation process. All that we would need to do is install the remote debugging components using the link below following the instructions under the section ‘To install remote debugging components (non-SQL Server 2005)’. And yeah, we would not need to worry about the remote debugging permissions since we are just debugging an application in the local machine in this case.

An interesting feature of SQL Server 2008 is the ability to pass tables as a parameter around in stored procedures. I know myself, I’ve found many times where I need to execute a stored procedure from another stored procedure and want to get the result back and then join against it in another stored procedure. An article over at www.SQLservercentral.com details this new feature.

Essentially you define a user type of type table then setup a parameter as table on the new stored procedure. Very straightforward.

Link to the article here

I use the Database Engine Tuning Wizard to analyze queries for performance. If you get the dreaded CRT error:

Microsoft has posted a nice knowledge base article on how to correct the problem here.

Part III – Connection Fail when SqlClient connects to Sql Server 2005

I found this article for troubleshooting Service broker and thought others might find it useful. I’ve just posted the summary and the link to the original is below.

When you connect to SQL Server 2005 either using “SQL Server Managment Studio” or any application compiled with .NET Framework 2.0, you are using SqlClient provider(Access data from within a CLR database object by using the .NET Framework Data Provider for SQL Server.)

Error Message 1:

An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)

Troubleshoot:
1) Make sure your sql service is running, use either “net start” or “sc query <InstanceName>” or run services.msc, check status of the server; If server start fail, go to ERRORLOG to see what happened there, fix the problem and restart server.

2) You might explicitly use “np:”prefix which ask for connect through named pipe. However, client can not connect to server through the pipe name that specified.Double check the server is started and listening on named pipe if you enabled Named Pipe. One way is that see the ERRORLOG of the server, search follow keywords:

Server named pipe provider is ready to accept connection on [ \\.\pipe\sql\query ] or [\\.\pipe\mssql$<InstanceName>\sql\query]

Notice that “sql\query” is the default pipe name, so you need to know server is listening on which pipe name. eg: if you specify server pipe name is “sql\query1″, then you would see in the errorlog that server listening on [ \\.\pipe\sql\query1 ], and go to SQL Server Configuration Manager, click client Named Pipe properties, see whether the pipe name is same with the one server listening on.

3) You might specify named pipe protocol in connection string, but did not enable named pipe on the server, check ERRORLOG.

4) You might use FQDN/IPAddress/LoopbackIP to connect to the server when only shared memory was enabled, you can change to <machinename> to resolve this.

5) You might explictly specify “lpc:” prefix in your connection string, but shared memory was not enabled. To resolve this, either remove the prefix as long as named pipe or tcp was enabled or enable shared memory.

Error Message 2:

A connection was successfully established with the server, but then an error occurred during the pre-login handshake. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (provider: Named Pipes Provider, error: 0 - No process is on the other end of the pipe.)

1) You might explicitly use “np:”prefix which ask for connect through named pipe and specify FQDN/LoopbackIP/IPAddress as server name in the connection string.
2) You might use FQDN/IPAddress/LoopbackIP to connect to the server.

To resolve 1) and 2), you can specify <machinename> instead of FQDN/IPADress/LoopbackIP.

More of the article…

Summary:

1) In any case, SqlClient should be able to connect to SQL Instance through any of the protocols(Shared Memory/Named Pipe/TCP) as long as SQL Instance was started successfully.

2) And if you speculate any protocol in connection string (”lpc:”/”np:”/”tcp:”), the error message would display “<Protocol> Provider, error <Num1> -….<Num2>.” <Protocol> stands for “Shared Memory” or “Named Pipes” or “TCP”; If you do not speculate
any protocol, the error message indicates that connection fails when connecting through specific <Protocol>.

3) In the error message format for SqlClient, please notice two different error number. <Num1> stands for internal error thrown out by SQL Protocols, <Num2> is the OS error(eg: 233 - No process is on the other end of pipe). When you see <Num1>=0, that means the connection fails due to OS error not caused by SQL Protocols, under this situation, you can use “net helpmsg” to check specific OS info.

Finally, if you were developing .NET framework application and came across above issues in your client app, the best way is first try SQL Server Management Studio to connect to SQL Server using the exact same connection string in your app, and watch the error message, normally, there is additional error info at the end of error string, eg ( Microsoft SQL Server, Error:87) which gives you clue(net helpmsg 87) that problem inside your connection string.

I found a nice trick for the Infragistic’s UltraWinGrid. The UltraGridRow has a property ListObject which can be cast to the original datasource object.  An example would be the following:

IList<CustObjectBE> orders = new List<CustObjectBE>();

UltraWinGrid grid = gridOrders; <– Grid on a form.

grid.DataSource = orders;

UltraGridRow row = grid.ActiveRow;

CustObjectBE order = row.ListObject as CustObjectBE;

if (order != null)

{

//Do something here.

}

This method provides a convenient way to get the bound object to a row in the grid.

This is my life… Works On My Machine

I found an interesting link on Microsoft’s web site today. http://msdn.microsoft.com/vstudio/express/beginner/kids/csharp/  C-Sharp for Kids. I’m not sure kids are going to be in to programming and if they are I think they need to get out and play some sports. Just thought this one was funny.