Monthly Archives: November 2011

Windows Can’t Acquire IP Address Via DHCP

0
Filed under Troubleshooting

I’ve run into a situation a few times where, for some unknown reason, a Windows machine will be unable to obtain an IP address via DHCP.

Then that happens, the machine is likely to get an APIPA address, such as 169.254.xxx.xxx. This is known as the DHCP failover situation, and generally, it’ll mean that while you might be able to see sites out on the internet, most likely, you won’t be able to see any computers connected to your internal network (often computers on your internal network will be associated with IP addresses of 192.168.xxx.xxx).

In my case, I could set static addresses for those affected computers and they’d work fine, but reset them back to using DHCP and they’d be unable to obtain an IP address.

Googling turned up a variety of possible solutions (unplug your router, reset the IP stack by deleting registry entries, plug your computer into a different power outlet <huh?>, running IPCONFIG /RELEASE….IPCONFIG /RENEW, etc), but nothing was working for me.

On a lark, I browsed over to my router (in this case a Verizon Fios router) to check it’s configuration.

I have several routers, but the Verizon router is the only one set up to be a DHCP server (there should only be one machine, router, or actual server, on your internal network set up as a DHCP server), and it all looked good, but then I noticed something.

I had a LOT of devices showing up in the connected devices list. Many were offline, but they were still there.

This means that the router was still holding leases for them and tying up those IP addresses. Hmmmm.

I counted. 21 of them.

So I navigated to the DHCP configuration screen of the router and lo and behold, I had it set to lease addresses from 192.168.100.100 to 192.168.100.120. Exactly 21 addresses!

Ugh.

Why?

Way back when I set up this router, my thinking was “I’ll never have more than 20 devices connecting, so why should I accommodate any more than that?” so I’d limited to the available IP address range that the router would pick from.

In retrospect, I suppose that was being a little to prematurely security-conscience.

It was that limit, along with a router than apparently does not like to recycle IP leases readily, that caused me to simply run out of DHCP addresses, and thus the failure of Windows to acquire an IP address.

Moral of the Story

At the end of the day, I probably shouldn’t have limited the router to 21 addresses. It seemed like a reasonable number, but these days, with several computers in each house, plus smart phones, TIVOs, internet-connected TVs, IPADs, laptops, game systems, etc, it’s completely conceivable to have far more than 20 devices or so vying for IP addresses through DHCP.

When I exhaust the range from 192.168.100.100 to 192.168.100.200, then I’ll know I have too much tech <g>!

Authoring VB6 IDE Addins in VB.net

41
Filed under .NET, Utilities, VB6

imageOk, Ok, I know what you’re asking yourself right now.

WTF would you want to do this?

But bare with me.

Realistically speaking, VB6 has a very limited shelf life. I have plenty of VB6 apps that run just fine under Win7 (even 64 bit), but Under Win8? Who knows.

But, the truth is, there are plenty of businesses that rely on WinXP and VB6 apps today, and those businesses aren’t converting those apps to .net (or anything else) particularly quickly.

As it happens, I’m currently doing some maintenance and upgrade work on a VB6 application, and, while it IS a 10+ year old IDE, it does have it niceties and not-so-niceties.

CodeSmart, MZTools, CodeHelper, and other add-ins can certainly help, but one thing I’ve definitely missed now that I’ve worked with VS2005+ is persistent bookmarks and breakpoints.

That fact that VB6 didn’t save bookmark and breakpoint locations is a real shame.

Now, people have asked about this capability for years. I found posts going back to 2001 asking for this function, but the only utility that even came close was the open source CodeDawg project. And while I still have the source here, I can no longer even locate a link for it on the web. No matter, really, because it never did work particularly well, would miss breakpoints or bookmarks that you set sometimes, and just generally had a terribly interface.

But it was a valiant attempt!

Fast forward to today, and I’m back in VB6, working in a large and not particularly straightforward codebase, and I find myself really needing bookmarks and breakpoints that I can set and come back to the next day or whenever.

But .net provides so much simpler coding paradigms for many things now (generic collections, and direct support for subclassing anyone!) that after a few days working up a prototype add-in in VB6, I couldn’t stand it and had to see if it was possible to put something together in .net.

That’s right. A VB6 addin written in VB.net 2010!

It’s not quite finished yet, so I’ll hold off on presenting the full monty for now, but it most certainly is doable, and actually makes for a quite nice development and debugging experience.

First, fire up VS2010 and create a DLL Library project.

In the project  properties, you’ll need to make sure to check the “Make assembly COM visible”

image

Next, On the compile tab, you need to set “Register for COM Interop”

image

You’ll also need to add a reference to the VBIDE.DLL file:image

You can usually find the file under the COM tab on the Add Reference screen:

image

Finally, create a new CLASS, call it Connect, and paste this:

<ComClass("96861C1E-73A0-46E2-9993-AE66D2BC6A91", "1AEA0235-959D-4424-8231-8EBB9B9C85FE")> _
<ProgId("BookmarkSave.Connect")> _
Public Class Connect
    Implements VBIDE.IDTExtensibility

    Private _App As Application

    Public Sub OnAddInsUpdate(ByRef custom As System.Array) Implements VBIDE.IDTExtensibility.OnAddInsUpdate
        _App.OnAddInsUpdate(custom)
    End Sub

    Public Sub OnConnection(VBInst As Object, ConnectMode As VBIDE.vbext_ConnectMode, AddInInst As VBIDE.AddIn, ByRef custom As System.Array) Implements VBIDE.IDTExtensibility.OnConnection
        Try
            If _App Is Nothing Then
                _App = New Application
            End If
            _App.OnConnection(VBInst, ConnectMode, custom)
        Catch ex As Exception
            ex.Show("Unable to start addin.")
        End Try
    End Sub

    Public Sub OnDisconnection(RemoveMode As VBIDE.vbext_DisconnectMode, ByRef custom As System.Array) Implements VBIDE.IDTExtensibility.OnDisconnection
        _App.OnDisconnect(RemoveMode, custom)
    End Sub

    Public Sub OnStartupComplete(ByRef custom As System.Array) Implements VBIDE.IDTExtensibility.OnStartupComplete
        _App.OnStartupComplete(custom)
    End Sub
End Class

Now to explain a few things.

The two GUIDs you see in the first COMCLASS line, you’ll need to generate your own unique id’s for them.

Obviously, the ProgID will also need to be changed (the general convention is {addin-name.Connect}).

The Application object is my actual core addin application. I’ve intentionally kept all the addin’s code OUT of the Connect class, to keep it simple, and because this class MUST be made visible to COM so that VB6 itself can instantiate the CONNECT object (and thus kickstart your addin). Usually, the less “stuff” you have to expose to COM in a .net assembly, the better, and this represents the bare minimum.

To make debugging seamless, be sure to set the Debug Start Action to “Start External Program” and point it at your VB6.EXE file:

image

You’ll also need to make sure your addin is registered with VB6, so it will know to load it along with any other addins. You do that by creating a key like the “BookmarkSave.Connect” key below:

image

Be sure to change the “BookmarkSave.Connect” to whatever ProgID you’ve decided on.

Give it a whirl

With all that in place, you should be able to RUN your addin from VS2010, VB6 should start and your addin CONNECT object’s OnConnection method should be called.

Now it’s time to pull out my Duran Duran and SoundGarden discs and get to coding some good ol’ fashioned pseudo-OO VB6 goodness!

Determining Whether you’re in DesignMode in a Windows Phone 7 Project

3
Filed under .NET, Windows Phone 7

When you’re building usercontrols in a Windows Phone 7 project, it’s often necessary to know whether the code is running in Design Mode (i.e. being invoked by the Visual Studio IDE or by Expression Blend), or whether you’re actually running in the real program.

It’s a trivial matter, really, but it can be hard to remember exactly how to do it when I need it, so I wrapped it in an IsInDesigner function:

    Public Function IsInDesigner() As Boolean
        Return System.ComponentModel.DesignerProperties.IsInDesignTool
    End Function