Error on now-absent tool window

[joe.mag]

We used to implement a tool window in our custom package as a way to expose a user interface to manage some custom data. The tool window ended up being a bad choice for this UI since it was really too wide for a tool window so we switched to a more conventional editor so the UI gets its own tab.

When the updated package was deployed I had to re-register in order for other UI changes I'd made to take effect. They did so I assume SoftPro is properly aware of the new package's interaces and UI elements. All the new features work as expected. Also, for background, we're on a Terminal Server with all the tiers of the system on one machine so all users share the same client install.

Here's the problem: One user had that tool window docked in SPS prior to the package upgrade. Now, when she opens SPS the tool window still appears to be present and docked but is collapsed. if she clicks to expand the tool window SPS faults and dies.

In thinking that the window placement data was likely just stale I tried deleting her UserLayout.xml file in her AppData/Local/SoftPro/Select/2.6 folder. SPS created a new xml file once she opened it fresh but the phantom tool window was still present in the UI. Furthermore, her SPS eventually threw an error "Failed to find or create a tool window matching the guid 'e74a0fda-bb2b-44dc-b012-309d5b221d23'." until I restored the original xml file from the backup I'd made. I did use this guid to edit the xml file to remove all references to that defunct tool window but when she loads this layout xml file the window still shows up and, when she exists SPS, it's been rewritten to the xml file. So obviously that's a dead end.

So here's my question: How can I safely get rid of that defunct docked window from her UI? Where is the fact that that window is even supposed to be there stored? No one else in my company has this problem but then no one else was using that tool window.

TIA

[john.morton]

Before you re-registered the package, did you attempt to unregister it? The process is exactly the same as registering, but using "unregister" instead of "register"

spregpkg.exe /m:unregister /p:”YourLibraryNameHere.dll”
select.exe /setup

[joe.mag]

It turns out the problem was due to the user having the window pinned in their UI. After the window class was unregistered the SPS UI would still try to load the window since it was pinned.

The fix was to
1) unregister the current package
2) Regiser an old instance of the package that still had the tool window in it
3) Have the user open Select, unpin the window, exit Select
4) unreg the old pkg
5) regiser the current package

problem is now gone.

[john.morton]

Thank you for taking the time to post your resolution.