July 2009 - Posts

Security Update for VS 2008 SP1 may not install
29 Jul 2009 5:33 PM

Microsoft released several security updates yesterday, including the Security Update for VS 2008 SP1. Today I installed them, but the VS 2008 one didn't install. I tried several times, but each time it still showed up as available in Windows Update.

Turns out that the update won't install if you didn't install C++ when you installed Visual Studio. I don't do C++, so I never install it and take up the disk space. Who knew that would someday prevent a security update from installing?

Hopefully, Microsoft will issue an update to the update in the near future, but in the meantime, there is a workaround. Thanks to Joao Cardoso, a VB MVP, for posting the following step by step on his blog (http://pontonetpt.com/blogs/joaocardoso/archive/2009/07/29/kb971092-visual-studio-2008-service-pack-1-atl-security-update-does-not-install.aspx).

1 - Download VS90SP1-KB971092-x86.exe from here
2 - Start the installation
3 – You will get an error message. Usually: “VC Libraries QFE Patch does not apply, or is blocked by another condition on your system.” 
4 - Don’t close the window, and find the temporary folder that was created in one of your drives. You may need to change your setting to see invisible folders. Usually this resides on the C drive and its a bunch of letters and numbers. Its a folder that has the file VS90SP1-KB971092-x86.msp in it. Copy the entire folder to another location and rename it to your liking.
5 - Finally cancel the installation process 
6 - Navigate to <drive>:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools and find vsvars32.bat.
7 - Change the permissions (on security) on the file to allow everyone to edit it. This may not be required but better safe than sorry, because the patch will edit this file.
8 - Finally start VS90SP1-KB971092-x86.msp from within the saved folder and the process should complete. Go to windows update and check for new updates. The patch should not be offered again.

by RobertG | 1 comment(s)
Filed under:
How do you connect to a remote SQL Server if you have SQL Server 2008 and Windows 7?
17 Jul 2009 10:15 AM

In my previous post, I covered how you configure SQL Server to let you connect to it from a remote computer. I used SQL Server 2005 because that is what I have on my laptop. I have not switched to SQL Server 2008 on that computer because I use it to write courseware and we have been using SQL 2005 in the courseware, primarily because VS 2008 installs SQL 2005.

In this post, I will cover two additional scenarios. You have Windows 7 installed and you are using SQL Server 2008. The basic steps are the same. You still need to configure protocols and ports and configure the firewall. The UI is different thought.

First off, SQL Server 2008 does not include the SQL Server Surface Area Configuration tool. So you will do all the configuring in the SQL Server Configuration Manager. Expand the SQL Server Network Configuration node. Select Protocols for MSSQLSERVER. Right-click on TCP/IP and select Enable. Do the same for Named Pipes if you want to use that.

To configure the port, double-click on TCP/IP. In the TCP/IP Properties dialog box, select the IP Addresses tab. Scroll down to the bottom. By default, SQL Server is configured to listen for clients on dynamic ports. To have it listen on the same port each time, leave the TCP Dynamic Ports property blank and set the TCP Port property to a number. If you do not use dynamic ports, SQL Server will use port 1433 by default for TCP. Click OK to dismiss the TCP/IP Properties dialog box.

Repeat these steps for SQLEXPRESS. Don't use the same port number. I used 1500 on my computer.

To have these changes take affect, you have to restart the SQL Server services. In the Configuration Manager, select SQL Server Services. Right-click on MSSQLSERVER and select Restart. Do the same for SQLEXPRESS.

Finally, you need to configure the Windows Firewall to enable communcation on these ports. In the Control Panel applet, double-click Windows Firewall. Select the Advanced Settings link.

 Either double-click Inbound Rules in the left pane or scroll down in the middle pane and select the Inbound Rules link.

Click New Rule in the Actions pane.

 In the New Inbound Rule Wizard, select Port and click Next.

Select TCP and enter the two ports you configured.

 Click Next twice. I accepted the defaults on each screen. Then provide a name for this rule. Click Finish. Use the same steps to add a rule for UDP and port 1434. 

You can now connect to SQL Server 2008 and SQL Server 2008 Express running on a remote Windows 7 computer.

by RobertG | with no comments
Filed under:
How do you connect to a remote SQL Server?
16 Jul 2009 5:11 PM

Your first thought might be, you gotta write a blog post about this? Isn't it just automatic? No, in fact, it is not. By default, both SQL Server and SQL Server Express disable the ability for clients on other computers to connect to them. To enable enable remote connections, you need to configure protocols and ports and configure the firewall.

First, open the SQL Server Surface Area Configuration tool. Then select the Surface Area Configuration for Services and Connections link. Click Remote Connections in the left page.

 To enable remote connections, select Local and remote connections and then choose either to use TCP only or both TCP and named pipes. Several people have reported that TCP works more reliably.

Do this for both MSSQLSERVER and SQLEXPRESS. You will need to restart both for the changes to take effect. Click OK to close the SQL Server Surface Area Configuration tool.

Now open the SQL Server Configuration Manager. Now expand the SQL Server 2005 Network Configuration node. Select Protocols for MSSQLSERVER. You should see that Named Pipes and TCP are enabled or disabled depending on what option you selected in the Surface Area Configuration tool.

 You now need to configure the port(s) SQL Server will use. Double-click TCP/IP. Select the IP Addresses tab. Scroll down to the bottom. By default, SQL Server is configured to listen for clients on dynamic ports. To have it listen on the same port each time, leave the TCP Dynamic Ports property blank and set the TCP Port property to a number. If you do not use dynamic ports, SQL Server will use port 1433 by default for TCP.

 Click OK to dismiss the TCP/IP Properties dialog box. Configure a port for the other instance of SQL Server but do not use the same port number.

Select SQL Server 2005 Services. Right-click on MSSQLSERVER and select Restart. Do the same for SQLEXPRESS.

Finally, you need to configure the Windows Firewall to enable communcation on these ports. In the Control Panel applet, double-click Windows Firewall. On the Exceptions tab (XP or Vista) click Add port. In the Edit a Port dialog box, add an exception for port 1433 using TCP.

Click OK to close the Edit a Port dialog box. Next, add an exception for port 1434 using the UDP protocol. Then add an exception for port 1500 (or whatever you used) using TCP.

Now, you can connect to either SQL Server or SQL Server Express from another computer.

by RobertG | with no comments
Filed under:
Missing stored procedures in LINQ course chapter 5
7 Jul 2009 12:56 PM

A customer wrote in today with an issue he was having in chapter 5 (More LINQ To SQL) of the LINQ course. The sample application calls two stored procedures (AddOrder and AddOrderDetail) in the Northwind database. These stored procedures are not created when you install Northwind. I wrote them.

Unfortunately, I neglected to include instructions on how to create these and so when you run the Transactions sample in chapter 5, you get an error. I apologize for this. Attached to this post is the code to create these stored procedures. The file also includes code to create four other stored procedures that are used in chapter 4. That chapter includes instructions on how to create them, but they are in the file anyway.

In case you have difficulty downloading the file, here is the code for the AddOrder and AddOrderDetails stored procedures. Again, I apologize for the confusion and my omission.

USE Northwind
GO

CREATE PROCEDURE [dbo].[AddOrder]
(
  @CustomerID nchar(5),
  @EmployeeID int,
  @OrderDate datetime,
  @RequiredDate datetime,
  @ShipVia int,
  @Freight money,
  @ShipName nvarchar(40),
  @ShipAddress nvarchar(60),
  @ShipCity nvarchar(15),
  @ShipRegion nvarchar(15),
  @ShipPostalCode nvarchar(10),
  @ShipCountry nvarchar(15)
)
AS
INSERT INTO [dbo].[Orders] ([CustomerID], [EmployeeID],
  [OrderDate], [RequiredDate], [ShipVia],
  [Freight], [ShipName], [ShipAddress], [ShipCity],
  [ShipRegion], [ShipPostalCode], [ShipCountry])
VALUES (@CustomerID, @EmployeeID, @OrderDate,
  @RequiredDate, @ShipVia, @Freight,
  @ShipName, @ShipAddress, @ShipCity, @ShipRegion,
  @ShipPostalCode, @ShipCountry);
 
RETURN SCOPE_IDENTITY()

GO

CREATE PROCEDURE [dbo].[AddOrderDetail]
(
  @OrderID int,
  @ProductID int,
  @UnitPrice money,
  @Quantity smallint,
  @Discount real
)
AS
 /* SET NOCOUNT ON */
INSERT INTO [dbo].[Order Details] ([OrderID], [ProductID],
  [UnitPrice], [Quantity], [Discount])
VALUES (@OrderID, @ProductID, @UnitPrice, @Quantity, @Discount);

GO

by RobertG | with no comments
Why doesn't Visual Studio release files?
6 Jul 2009 3:53 PM

I have had a long running issue where Visual Studio won't release files and so I can't delete them or move them. 

This happended to me a couple of weeks ago:

1.       I copied a DLL to my computer.

2.       I set a reference to that DLL in a project.

3.       I decided I want a different DLL.

4.       I removed the reference to that DLL from my project.

5.       I tried to delete the DLL from my computer.

What happened? Visual Studio was still using the file, so Windows wouldn’t let me release it. This happened with VS 2008 and Vista. It also happened with VS 2010 and Windows 7.

 

Related to this is renaming a folder. I create a project. I rename it. I decide I want to rename the folder it is in. I close the solution. Windows won’t let me rename the folder. I close Visual Studio. Windows still won’t let me rename the folder. I have to reboot the computer. This has happened numerous times with VS 2008 and Vista. I have not tried it with VS 2010 and Win 7 yet.

I asked a contact on the VB team if this is a known issue and would they fix it. My contact forwarded my mail to someone on the VS Platform team. The response I got was that these types of issues are very hard to nail down. Any component interacting with the DLL could be holding a reference to it. This includes the project system, MSBuild, IntelliSense, the VS designers. He wanted to know if this was happening on a particular project or DLL. Unfortunately, the answer to that is no. I have seen this on numerous projects, more often than not C# rather than VB.

Have you seen this? Have you seen it in specific scenarios? If you have, let me know and I will forward your experinece on to the VS Platform team. The more info we can give them, the more chance we have of them fixing this most annoying behavior.

 

by RobertG | with no comments
Filed under: