11

I am cleaning up a C# Visual Studio 2008 solution and have run into a snag. I am trying to remove unnecessary files in preparation for placing the code under proper revision control. In doing this I deleted the existing .suo file and all binary artifacts to get a clean start. When I do this my program is unable to access the connected barcode scanner through the Microsoft.PointOfService library. I have narrowed down the problem to something in the .suo. If I preserve the original .suo I can retrieve the list of connected scanners. With a fresh one, the connected scanner doesn't show up in the call to PosExplorer.GetDevices().

It isn't clear to me why anything related to the .suo would affect the behavior of a program. The solution contains three projects, two of which are referenced by the main application. While tracking this issue down in testing I find that the references to these two projects sometimes break with the clean .suo and have to be reestablished. They have nothing to do with the scanner though. I also have to reenable the debug build configuration for the top level project.

Any ideas? I'd rather not have to check in the legacy .suo if I can avoid it.

Update

I noticed that additional scanner driver DLLs (HHSO4NET.dll) are getting loaded when the functional legacy .suo is in use. The changed portions of the VS output window are listed below.

Legacy .suo output window:

'foo.vshost.exe' (Managed): Loaded 'C:\Program Files (x86)\Honeywell\UPOS Suite\POS4NET Suite\POS for NET\bin\HHSO4NET.dll'
'foo.vshost.exe' (Managed): Loaded 'C:\Windows\assembly\GAC_MSIL\Microsoft.PointOfService.ControlBase\1.12.0.0__31bf3856ad364e35\Microsoft.PointOfService.ControlBase.dll'
'foo.vshost.exe' (Managed): Loaded 'C:\Program Files (x86)\Microsoft Point Of Service\SDK\Samples\Simulator Service Objects\Microsoft.PointOfService.DeviceSimulators.dll'
'foo.vshost.exe' (Managed): Loaded 'C:\Program Files (x86)\Microsoft Point Of Service\SDK\Samples\Example Service Objects\Microsoft.PointOfService.ExampleServiceObjects.dll'
'foo.vshost.exe' (Managed): Loaded 'C:\Program Files (x86)\Honeywell\UPOS Suite\POS4NET Suite\POS for NET\bin\HHSO4NET.dll'
'foo.vshost.exe' (Managed): Loaded 'C:\Windows\assembly\GAC_MSIL\Microsoft.PointOfService.ControlBase\1.12.0.0__31bf3856ad364e35\Microsoft.PointOfService.ControlBase.dll'

Clean .suo output window:

'foo.vshost.exe' (Managed): Loaded 'C:\Program Files (x86)\Microsoft Point Of Service\SDK\Samples\Simulator Service Objects\Microsoft.PointOfService.DeviceSimulators.dll'
'foo.vshost.exe' (Managed): Loaded 'C:\Windows\assembly\GAC_MSIL\Microsoft.PointOfService.ControlBase\1.12.0.0__31bf3856ad364e35\Microsoft.PointOfService.ControlBase.dll'
'foo.vshost.exe' (Managed): Loaded 'C:\Program Files (x86)\Microsoft Point Of Service\SDK\Samples\Example Service Objects\Microsoft.PointOfService.ExampleServiceObjects.dll'

Update 2

I've reproduced the problem with the legacy .suo by uninstalling the previously installed release version of the program (msi installer from a VS deployment project). It would seem that a registry reference to the HHOS4NET.DLL created by the installer is picked up when the build is done with the legacy.suo and not a fresh one. Any ideas where to look for a culprit?

Update 3

It seems that the uninstallation of the working application was a bit of a red herring. It wiped out the Configuration.xml file the scanner driver depends on to see the scanner (PnP? Yeah right). That still leaves me with a mysterious magic .suo. I tried enumerating the connected POS devices using a simple C# console app and that didn't work so something is definitely fubared with MS's POSfor.NET framework or Honeywell's driver. They truly are a POS.

For the record there are no special debug settings in the known "good" .suo. I extracted strings from it and nothing stood out. Next I'm going to try plopping it into the console app to see if it retains its magical properties in an unrelated solution.

Kevin Thibedeau
  • 3,299
  • 15
  • 26
  • Maybe there's a special debug command-line argument? Those are saved in the .suo. – Cameron May 02 '14 at 16:29
  • Are there default command line parameters or working directory set in the debug tab for the project? – Rowland Shaw May 02 '14 at 16:30
  • Anything custom under Project Properties -> Debugging? Might be time to break out Sysinternals's Process Monitor. – Cameron May 02 '14 at 18:48
  • Are there any left over bin or obj folders in any on the project folders? If so delete them and the support file and reload everything. When I worked on some hand held apps myself and other developers would need to do this from time to time. Also you are keeping it in vs2008 right. I asked because Microsoft dropped support for the compact framework in later versions. – dklingman May 03 '14 at 00:43
  • @dklingman. I cleaned out all build products including previously existing binaries. The build works fine. It's just the running application that fails (due to the unloaded DLL most likely). This is all in vs2008. – Kevin Thibedeau May 03 '14 at 12:23
  • I think that there can be build order data in the suo. Try going in and setting up project references and dependencies again and see if that helps. It seems like a possibility that something isn't getting built and deployed to the right order/location. – justin.m.chase Jun 18 '14 at 03:50
  • Some ways to extract/view the contents of the suo file: http://stackoverflow.com/questions/54052/tool-to-view-the-contents-of-the-solution-user-options-file-suo – Justin Killen Jul 02 '14 at 16:22
  • Could you try some kind of assembly redirection in the app.config to force the evaluation of these assemblies? Or a reference include in the app.config instead? – Mark S Jul 28 '14 at 13:45

1 Answers1

0

Check whether the SUO targets a specific bitness. Sometimes you have to be explicit. Going on your output the trouble starts when it fails to load

Program Files (x86)\Honeywell\UPOS Suite\POS4NET Suite\POS for NET\bin\HHSO4NET.dll

Wrong bitness can mess up load paths and name resolution. Do you have any other paths defined in the magic SUO? Can I have a copy of it to dissect?

Peter Wone
  • 17,965
  • 12
  • 82
  • 134