Connect to SQL Server Instance on Virtual Machine from Host Machine Running Vista

by Ted Jardine Friday, July 27, 2007 5:26 PM

A couple months back when I first switched my primary developer machine to Vista, I wanted to connect to a SQL Server 2000 instance on my WinXP Pro virtual machine (Virtual PC 2007). It took a bit of digging to figure out how to a) even do it with WinXP to WinXP and then b) do it with Vista as the host OS.

Typically, it's an easy thing to set up your virtual machines to talk to each other, and also talk to the host machine, but to get the host machine to be able to talk to the virtual we need to go a little further by configuring a Microsoft Loopback Adapter. Using the Microsoft Loopback Adapter opens our Virtual Machine only to the host. To do this in Vista, do the following:

  1. Install a Loopback Adapter
    1. Open Control Panel
    2. Vista caveat: switch to Classic View to "Add Hardware"
    3. In the "Welcome to the Add Hardware Wizard", click Next.
    4. Select "Install the hardware that I manually select from a list (Advanced)" and click Next.
    5. Scroll down and select "Network adapters" and click Next.
    6. Select under Manufacturer "Microsoft" and then under Network Adapter "Microsoft Loopback Adapter" and click Next.
    7. Click Next and Finish.
  2. You can manually configure your IP Address for your adapter, but you can just let the loopback adapter get an auto configuration IP address from your router's DHCP.
  3. In your Virtual PC Console, choose settings for the applicable virtual machine, and then choose "Networking".
  4. Select the now available "Microsoft Loopback Adapter" (note that your virtual machine will need to be off, not in a saved state, in order to make this change).
  5. Turn on your virtual machine and once it's booted up, verify that the Microsoft Loopback Adapter has installed its routing in your host PC's route table by going to a command prompt in the virtual machine and typing "route print".
  6. In the case of a virtual machine running WinXP, make sure you've allowed file and print sharing in the virtual machine's firewall settings.
  7. Open a command prompt and run ipconfig to find out what your virtual machine's IP address is (note that as we have not configured the Microsoft Loopback Adapter to allow the virtual machine to connect to the outside network, your task bar network icon will warn you that you have limited connectivity – thus the need to run ipconfig from a command line to see if the virtual machine even has an IP address assigned).
  8. Check whether your host machine can now communicate with the client virtual machine by pinging it's IP address by opening a command prompt in Vista and typing "ping 169.254.166.12" where you enter your applicable IP address.
    c:\>ping 169.254.166.12
    Pinging 169.254.166.12 with 32 bytes of data:
    Reply from 169.254.166.12: bytes=32 time=1ms TTL=128
    Reply from 169.254.166.12: bytes=32 time<1ms TTL=128
    Reply from 169.254.166.12: bytes=32 time<1ms TTL=128
    Reply from 169.254.166.12: bytes=32 time<1ms TTL=128
    Ping statistics for 169.254.166.12:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 1ms, Average = 0ms
  9. And voila, you've now successfully networked your host machine to talk with your client virtual machine.

If you still want internet access for your client virtual machine, do the following:

  1. Open your Network and Sharing Center
  2. Click Manage network connections in the left hand navigation bar
  3. Right-click the loopback connection and select properties.
  4. In the sharing tab, enable “Allow other network users to connect through this computer's Internet connection.

This "should" work, but I initially encountered "an error occurred while Internet Connection Sharing was being enabled." However, it resolved soon afterwards all by itself.

The article that was the biggest help in getting the above in place was http://www.governmentsecurity.org/archive/t10129.html

UPDATE: Change to post title.

Testing websites that use SMTP email on Vista

by Administrator Wednesday, July 18, 2007 5:29 PM

Many of the ASP.NET web applications we build use SMTP to send email for one reason or another. Order confirmations, mostly, or selected search results.

Testing code that sends email has always been a pain. We have servers with SMTP service that I could point at from my development workstation, but their various restrictions have been, well, restricting. Nor did I ever like the idea of letting SMTP run openly on my local machine in XP. Not that I had much choice, because a) I had to ensure that the code I wrote followed through with the email send, and b) I wanted to view the email as email to ensure it looked the way it ought.

So along comes Vista with IIS 7. And SMTP is not included. It is included with Longhorn Server 2008 with IIS 7 (apparently), but not Vista. I now no longer have the choice of running SMTP locally. Disaster!

Well, as it happens, I'm fine. I'm better than fine, because I stumbled across a better solution all around. I use a pickup directory location.

Using a pickup directory location lets me specify a folder on my local machine for the email generated by System.Net.Mail. It's not sent anywhere, it's just dumped in that location as a *.eml file which can be viewed by Vista's built-in Windows Mail.

The best thing is, I don't have to change my code in any way to make this happen. I only need to add a snippet to the web.config as follows, identifying the (absolute) directory for pickup:

<system.net>
  <mailSettings>
    <smtp deliveryMethod="SpecifiedPickupDirectory">
      <specifiedPickupDirectory 
pickupDirectoryLocation="v:\inetpub\mailroot\pickup"/>
    </smtp>
  </mailSettings>
</system.net>

I did have to make sure that the ASP.NET worker account, NETWORK SERVICE, had read/write access to that location.
And here's the result. One double-click and I get to see it as it would appear in my inbox:
CropperCapture[17]
Probably other developers are like, well *duh*, but this was a new and very pleasant discovery for me.

Search open source code with Koders

by Peter Tyrrell Friday, July 13, 2007 11:20 AM

Koders.com is a search engine that searches a large library of open source code. It's also a product you can purchase and point at your own codebase, but it's the easy access to all manner of reusable code, in just about any language, that has my beanie propellor whirling.

You can rather quickly find out how other developers have used method X in a given API, for instance. Seeing .NET examples in use in the wild is a much more potent educational tool than than the skeletal examples on MSDN, personally speaking.

You can also look for working examples of a concept. How have others approached solving problem Y? A browse through the relevant search results can show you real code being used in real life. Because honestly, if you are faced with a tough nut to crack, chances are someone else has already cracked it.

It gets better, because not only can you learn from your research, you can pick it up and use it wholesale. Or at the least, adapt the solution to your specific needs.

So the ability to search for code is, alone and all by itself, very useful. But you can you also browse through entire software projects! Holy crap. I spent some time just grazing:

Koders also provides a Firefox search engine plug-in, and a Visual Studio plug-in: Koders Plug-Ins. I am cozying up to both.

Tags: tools

dtSearch compared favorably to Google Mini search appliance

by Administrator Wednesday, July 11, 2007 11:48 AM
A recent review in ChannelWeb (June 28th, 2007) of the Google Mini search appliance compares it with the dtSearch product line: "The biggest sore spot with the Mini is its $2,000 price tag. Competing vendor dtSearch, a channel-friendly vendor, offers a much better solution. For $999 per server, dtSearch offers a robust search engine with a comprehensive Win and .Net API. dtSearch's engine can connect to any file system, including Web content, and it is not limited to a page count. Solution providers can build custom interfaces, integrate the engine with any custom application and package a solution on any hardware that can meet customer requirements. Solution providers can ratchet it up as much as they want. dtSearch also has a dedicated site for third-party developers that provide development services."

Andornot is a registered dtSearch developer - see our dtSearch product info page or check out our own Andornot site search.

If you are looking for a value packed document, email and website search engine, contact Andornot for more information.

Tags: News | dtSearch

ASP.NET AJAX and Sys.Webforms.PageRequestManagerServerErrorException

by Ted Jardine Monday, July 09, 2007 11:23 AM

Using ASP.NET AJAX extensively in my latest project I've been sporadically running into the Sys.WebForms.PageRequestManagerParserErrorException. It got to the point that I was contemplating ripping out ASP.NET AJAX completely until this known issue had been ironed out. The various causes for this error are mentioned many different places, but for some samples, go here, here, and here.

Quoting from Eilon Lipton's blog posting, this particular exception is very common and can be caused by any one of the following:

  1. Calls to Response.Write():
    By calling Response.Write() directly you are bypassing the normal rendering mechanism of ASP.NET controls. The bits you write are going straight out to the client without further processing (well, mostly...). This means that UpdatePanel can't encode the data in its special format.
  2. Response filters:
    Similar to Response.Write(), response filters can change the rendering in such a way that the UpdatePanel won't know.
  3. HttpModules:
    Again, the same deal as Response.Write() and response filters.
  4. Server trace is enabled:
    If I were going to implement trace again, I'd do it differently. Trace is effectively written out using Response.Write(), and as such messes up the special format that we use for UpdatePanel.
  5. Calls to Server.Transfer():
    Unfortunately, there's no way to detect that Server.Transfer() was called. This means that UpdatePanel can't do anything intelligent when someone calls Server.Transfer(). The response sent back to the client is the HTML markup from the page to which you transferred. Since its HTML and not the special format, it can't be parsed, and you get the error.

The problem was I wasn't doing any of the above (who uses Response.Write in an ASP.NET application these days?) and I was still sporadically encountering the error - a show stopping error I might add. An error that is popped up in a javascript warning box completely undecipherable to the end user leaving an empty/useless/castrated UpdatePanel in its wake. This of course leaves the end user feeling likewise empty/useless/castrated (to say nothing of the developer).

This post here indicates that there is a problem with the RoleMangerModule or any time you set a cookie to the response in an AJAX callback, which can only be solved by doing one of the following:

  1. Disable caching of cookies in the RoleManager. (yuck)
  2. Handle the Application's Error event to clear the error from the Context selectively (eek).
  3. Disable EventValidation in the web form.
    <%@ Page Language="C#" EnableEventValidation="false" %>
    (gulp)

None of the above are entirely reasonable solutions (especially the last two), and the worst part was that my test page was just a simple contact page that did not change/set roles or cookies, or response.write, or set anything in the session, and wasn't receiving any Unicode character input, or even requiring a user to be logged in, or writing anything to the trace, or anything beyond the basics. And still it blew up. But only occasionally.

In order to faithfully reproduce the error, I finally determined that it must have something to do with sessions as it would only occur if the app pool had recycled and all browser windows had been closed. So, based on one of the comments in one of the above posts, even though I'm not touching session on one of the problem pages, I tried a hack in one of the problem page's Page_Load:

Session["FixAJAXSysBug"] = true;

And lo and behold, we're good to go! So even though I am not using Session on the problem page it must be attempting to set the initial session cookie using the Update Panel callback. So the solution is to make sure the initial session is set before any Update Panel callback takes place. How this got through into production is beyond me.

So if you're sporadically encountering the Sys.Webforms.PageRequestManagerServerErrorException, it could be for any of the above reasons or the fact that your dog/cat/stuffed teddy bear is sitting too close to your monitor. But give the last one a try in every page utilizing AJAX if you're using sessions in your application.

UPDATE: If the problem pages aren't even using session, just turn session off for the page:

<%@ Page EnableSessionState="false" ... %>

Or better yet, set it in your base class to always be off, and turn it on for the pages where you need it on.

UPDATE II: Further developments.

Month List