2014-05-02 9 views
10

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.

+0

Forse c'è uno speciale argomento da riga di comando per il debug? Quelli sono salvati nel .suo. – Cameron

+0

Nella scheda di debug del progetto sono presenti parametri della riga di comando o directory di lavoro predefiniti? –

+0

Qualcosa di personalizzato in Proprietà progetto -> Debugging? Potrebbe essere il momento di rompere il Process Monitor di Sysinternals. – Cameron

risposta

0

Verificare se il SUO si rivolge a un determinato testimone. A volte devi essere esplicito. Proseguendo l'output cominciano i guai quando non riesce a caricare

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

bitness sbagliato può rovinare percorsi di carico e la risoluzione dei nomi. Avete altri percorsi definiti nel SUO magico?Posso avere una copia di esso per sezionare?

Problemi correlati