How I stopped worrying and learned to love Interop!
Για κάποιο λόγο (μή ρωτάτε γιατί) τον τελευταίο καιρό είμαι υποχρεωμένος να καλώ ActiveX dlls στα οποία πρέπει να περάσω ADO connections. Η εμπειρία δεν μπορώ να πω ότι ήταν και η πιο ευχάριστη. Βλέπετε, όταν βάζει κανείς reference σε ένα activex dll το οποίο δέχεται π.χ. παραμέτρους Connection το Visual Studio θα βρει και θα προσθέσει το κατάλληλο Interop assembly (adodb.dll). Το assembly αυτό βρίσκεται κανονικά στο C:\Program Files\Microsoft.NET\Primary Interop Assemblies. Έλα όμως, που δεν θα το προσθέσει και στο Deployment Project! Αυτή ήταν η κανονική λειτουργία στο Visual Studio 2003 (http://support.microsoft.com/kb/321688/en-us) αλλά όπως φαίνεται είτε άλλαξε, είτε εμφανίστηκε ένα bugάκι. Θα μου πείτε, κανένα πρόβλημα, αφού τα αρχεία θα υπάρχουν στους υπολογιστές των client...
Αμ δε! Σε κάποια μηχανήματα, παρότι εγκαθίσταται κανονικά το .NET 2.0 runtime, το folder με τα Interop Assemblies δεν δημιουργείται! Ίσως φταίει ότι τα μηχανήματα αυτά ήταν Windows 2003 Server, ίσως όχι. Όπως και να έχει, μετά από πολύ ψάξιμο, και αφού βρήκα και αυτό το ωραίο αρθράκι με τα προβλήματα του ADODB Interop (http://support.microsoft.com/kb/910696/en-us) άρχισα να πιστεύω ότι ίσως το Interop να μην είναι και τόσο καθαρή δουλειά όσο ακουγόταν στην αρχή. Κάτι το DLL Hell, (τί κάνεις αν εσύ χρησιμοποιείς μία version των dll, και τα μηχανάκια παλαιότερη?), κάτι τα bugάκια του Deployment Project, κατέληξα στο συμπέρασμα ότι ο μόνος τρόπος να βεβαιωθείς ότι θα δουλέψει ο κώδικας σου είναι να το δοκιμάσεις σε διαφορετικά PC τα οποία θα μοιάζουν όσο το δυνατόν περισσότερο με τα μηχανήματα στα οποία θα κάνεις deploy.
Είναι σίγουρα πολύ φασαρία, αλλά είναι και η μόνη λύση αν δεν θέλει κανείς να εξηγεί στον πελάτη γιατί η εφαρμογή πετάει περίεργα exceptions! Ας είναι καλά το Virtual PC και το VM Ware!