Sto pulendo una soluzione C# Visual Studio 2008 e ho incontrato un ostacolo. Sto cercando di rimuovere i file non necessari in preparazione del posizionamento del codice sotto il controllo di revisione appropriato. In questo modo ho eliminato il file .suo esistente e tutti gli artefatti binari per ottenere un avvio pulito. Quando eseguo questa operazione, il mio programma non è in grado di accedere allo scanner di codici a barre collegato tramite la libreria Microsoft.PointOfService
. Ho ristretto il problema a qualcosa nel .suo. Se conservo l'originale .suo, posso recuperare l'elenco degli scanner collegati. Con uno nuovo, lo scanner collegato non viene visualizzato nella chiamata a PosExplorer.GetDevices()
.Visual Studio SUO che rompe l'applicazione
Non mi è chiaro perché qualsiasi cosa correlata al .suo influirebbe sul comportamento di un programma. La soluzione contiene tre progetti, due dei quali sono referenziati dall'applicazione principale. Tralasciando questo problema nei test, trovo che i riferimenti a questi due progetti a volte si rompono con il .suo pulito e devono essere ristabiliti. Tuttavia non hanno nulla a che fare con lo scanner. Devo anche riabilitare la configurazione di compilazione di debug per il progetto di primo livello.
Qualche idea? Preferirei non dover controllare l'eredità .suo se posso evitarlo.
Aggiornamento
ho notato che ulteriori DLL del driver dello scanner (HHSO4NET.dll) sono sempre caricato quando l'eredità funzionale .suo è in uso. Le parti modificate della finestra di output VS sono elencate di seguito. finestra di output
Legacy .suo:
'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 finestra di output .suo:
'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
ho riprodotto il problema con il .suo legacy da disinstallando la versione di rilascio del programma installata in precedenza (msi installer da un progetto di distribuzione VS). Sembrerebbe che un riferimento al registro di HHOS4NET.DLL creato dal programma di installazione venga rilevato quando la compilazione viene eseguita con legacy.suo e non con una nuova. Qualche idea su dove cercare un colpevole?
Update 3
sembra che la disinstallazione dell'applicazione di lavoro è stato un po 'uno specchietto per le allodole. Ha cancellato il file Configuration.xml
da cui dipende il driver dello scanner per vedere lo scanner (PnP? Sì, vero). Questo mi lascia ancora con una misteriosa magia .suo. Ho provato a enumerare i dispositivi POS connessi utilizzando una semplice app per console C# e questo non ha funzionato, quindi qualcosa è decisamente rovinato dal framework POSfor.NET di MS o dal driver di Honeywell. Sono veramente un POS.
Per la registrazione non ci sono impostazioni speciali di debug nel noto "buono" .suo. Ho estratto le stringhe da esso e nulla si è distinto. Successivamente ho intenzione di provare a farlo cadere nell'app della console per vedere se mantiene le sue proprietà magiche in una soluzione non correlata.
Forse c'è uno speciale argomento da riga di comando per il debug? Quelli sono salvati nel .suo. – Cameron
Nella scheda di debug del progetto sono presenti parametri della riga di comando o directory di lavoro predefiniti? –
Qualcosa di personalizzato in Proprietà progetto -> Debugging? Potrebbe essere il momento di rompere il Process Monitor di Sysinternals. – Cameron