Unable to Connect to SQL Server While VPN Active

I've had the following problem for quite some time now, and finally resolved. At first blush, it seems like a simple enough issue to resolve, but in my particular case, it wasn't.

Basically what happened is that I have an instance of SQL (Express) installed on my primary development machine that is used as part of design, development, and building of the various applications I'm working on. I also have need to connect to a particular customer network via VPN (Aventail/SonicWALL). Everything was working fine until a few months ago when the customer updated the VPN client (from 9? to 10), at which point I was no longer able to access my SQL instance through trusted connection.

For example, if connected to the VPN and attempting a command line query, I'd see the following:

C:\>osql -S localhost\sqlexpress -q -E
Login failed for user ''. The user is not associated with a trusted SQL Server
connection.

In checking the event log, I'd see the following error:

SSPI handshake failed with error code 0x8009030c while establishing a connection with integrated security; the connection has been closed. [CLIENT: nnn.nnn.nnn.nnn]

If I disconnected the VPN, the above works as expected (no error).

?

My first conclusion was that the new VPN client was tunnelling ALL traffic through the appliance, and local requests back to my machine, and therefore SQL was considering the request as 'remote' and denying it. I tweaked the necessary SQL properties to allow remote connections -- nada.

After spending a lot of time trying to diagnose, I temporarily gave up and just resolved that I'd either be able to do VPN work or SQL work, but not both simultaneously.

Not satisfied with that 'solution', I resolved to spend more time on it. I'll leave out the countless things that I did try and didn't work and mention what I did find that actually solved the problem for me -- hopefully it will help someone else:

I started looking at the SQL configuration a little more closely (Start Menu\Programs\Microsoft SQL Server 2005\Configuration Tools\SQL Server Configuration Manager) and noticed some differences from some of the other typical SQL installations I have floating around. Specifically:

Under SQL Server 2005 Network Configuration: all protocols were enabled.
Under Aliases, there were several aliases using the tcp protocol.

I reset the above to coincide with what appears to be the default configuration:

SQL Server 2005 Network Configuration
  Shared Memory - Enabled
  Named Pipes - Disabled
  TCP/IP - Disabled
  VIA - Disabled

Deleted all SQL Native Client Configuration Aliases.

After that, my VPN/SQL issues were resolved! I'm not exactly sure what was the cause (protocol or alias), but a little more post-fix experimentation leads me to believe tha that the aliases were the problem. How that relates to the updated VPN client, or if it was purely coincidental, I don't know, but it is fixed and I'm satisfied!

Agile Development & "When will it be done?"

I've been doing XP/Agile development & management for 5 years now, and I've come to the conclusion that as soon as you have to answer "when will it be done?" you are back on the path to Waterfall.

What is the meaning of GC.KeepAlive()?

What is the purpose of GC.KeepAlive(object obj)? From the method name, it sounds like it will keep obj from being garbage collected after the call. In fact, the opposite is true, it will keep obj from being garbage collected before the call. On the face, that sounds like a pretty absurd method, doesn't it.

The problem is that the method is named incorrectly. Better, but more verbose, names would be GC.MakeExplicitlyElligibleForGarbageCollection() or GC.DontCollectObjectBeforeNow().

So, what's really going on here? As you are presumably well aware, memory is reclaimed in the .NET framework through garbage collection, which can happen at any time, for any object that has no outstanding references (but don't confuse with reference counting). For example:

public void SomeMethod()
{
 SomeClass o = new SomeClass();
 GC.Collect(); // no references to 0, it may be collected
 return;
}

Not very exciting, and makes sense, right? o isn't being used after the point of instantiation, so the collector is free to clean it up and reclaim the memory*.

But suppose that for some reason or another you need o to remain 'alive' until after SomeMethod() exits. In order to guarantee that, you would need to add some reference to 0 at the end of the method so that it can't be collected. That is the purpose of GC.KeepAlive().

So, all that GC.KeepAlive() does is create an artificial reference to 0 so that it can't be collected prior to the GC.KeepAlive() call:

public void SomeMethod_V2()
{
 SomeClass o = new SomeClass();
 GC.Collect(); // reference to 0 below, it will NOT be collected
 GC.KeepAlive(o);
 GC.Collect(); // no more references to 0, it may now be collected
 return;
}

So, hopefully the above makes it clearer what GC.KeepAlive() does, although we do need to figure out a better name...

*Note: In order to facilitate debuggers, when an application is compiled in Debug mode, the JIT will NOT collect locally-allocated instances until after the method exits. So, in this example, if compiled under Debug, o will never be collected until after SomeMethod() returns. In Release mode, locally-allocated instances can be collected after the point of last reference, even before the method has returned.

Resolving Error LNK2001: unresolved external symbol __imp__time

I don't know if this is a generic situation or not, but it has been frustrating to resolve. The scenario is that I'm building some C/C++ FLEXnet components and was having no fun on getting the Release build to compile and link. After much fiddling, I was able to resolve everything down to one link error:

Error LNK2001: unresolved external symbol __imp__time

After comparing the differences between Debug and Release settings, I ended up stumbling upon the "Whole Program Optimization" setting (Project, Properties, Configuration Properties, General).

In my case, the default for the Release build was set to: Use Link Time Code Generation -- seems reasonable. What isn't reasonable is how it leads to the above linker error. I still have no idea why it causes it, but changing it to No Whole Program Optimization solved the issue.

Note: using Visual Studio 2008, SP1

Get Method or Property Name as String in .Net

There are a few occasions where it is helpful to have the string name of the executing method or property.

The cleanest way that I've been able to devise is to use the query the current stack frame using System.Diagnostics.StackFrame.

string methodName = new StackFrame().GetMethod().Name;

When called from within a property, the name includes the getter/setter prefix: get_ or set_. Therefore, if you want the actual property name, use the following:

string propertyName = new StackFrame().GetMethod().Name.Split('_')[1];