Βρίσκομαι αντιμέτωπος με ένα ενδιαφέρον πρόβλημα.

Έχω ένα σύνολο από windows Application & windows Service solutions, τα οποία μοιράζονται μεταξύ άλλων, και ένα project (class library). Όλα τα παραγόμενα assemblies είναι signed, και καθορίζω ο ίδιος το versioning (δηλ. δεν είναι αυτόματο).

Το πρόβλημα είναι πως, όταν κάνω κάποια αλλαγή στο κοινό αυτό project, η αλλαγή πρέπει να γίνει και στα υπόλοιπα solutions, αλλιώς λαμβάνω μηνύματα λάθους, για αδυναμία εύρεσης της συγκεκριμένης έκδοσης του DLL. Οι εφαρμογές επικοινωνούνε μεταξύ τους με τη χρήση Sockets, όπου ακολουθείται το τυπικό "Binary Serialize -> Transport -> Deserialize).
Ωστόσο, οι αλλαγές οι οποίες γίνονται, δεν επηρρεάζουν τον ήδη υπάρχοντα κώδικα (πχ μπορεί να ζητήσω ένα αντικείμενο από τη μία εφαρμογή με έκδοση του common project 1.0.5.0, το οποίο δεν έχει αλλάξει στην έκδοση 1.0.5.1 του common project, που χρησιμοποιεί η άλλη εφαρμογή-αποστολέας).

Δουλεύω σε .net 2.0. Έχω δοκιμάσει να διατηρήσω ίδιο το νούμερο των εκδόσεων μεταξύ builds, χωρίς αποτέλεσμα. Αφαίρεσα το common project από 2 solutions και έβαλα reference αυτού ως DLL, με specific version στο false, αλλά δεν άλλαξε τίποτα. Αφαίρεσα μέχρι και το signing, επίσης χωρίς αποτέλεσμα.


Κάποια ιδέα για το αν αυτό είναι by design, ή κάνω κάτι λάθος; Ευχαριστώ προκαταβολικά!

---

Μην αφήνετε τα media να σας "ταΐζουν"!

Ίσως αν το βάλεις στο GAC, και το reference ΔΕΝ είναι copy local στα επιμέρους projects?

---

Angel
O:]

Το σκέφτηκα, αλλά δεν είναι τόσο ευέλικτη η λύση για τη δουλειά μου (είναι και αρκετά τα μηχανήματα).

Έχω έναν autoupdater ο οποίος μέσα σε 4 ώρες (το πολύ) θα ανανεώσει τα applications & τα services, αλλά δε θέλω να χτυπάει μέχρι να γίνει το update.

Το VTSerialization δε θα έπρεπε να με σώσει σ' αυτήν την περίπτωση (δεν είναι αυτόματο άλλωστε); Αύριο πάντως που θα πάω στη δουλειά, θα ρίξω μια ματιά στο FormatterAssemblyStyle.Simple, μη τυχόν και είναι αυτό που ψάχνω.

---

Μην αφήνετε τα media να σας "ταΐζουν"!

Εφ'όσον έιναι signed το assembly, το manifest περιέχει ένα hash του binary αρχείου (όπερ σημαίνει ότι ακόμα και μια μικρή αλλαγή να κάνεις - πχ με ένα hex editor σε ένα string - έχεις κάνει break το compatibility). Άρα, ακόμα και όταν δεν αλλάζεις το version number, οι εφαρμογές που χρησιμοποιούν το reference αντιλαμβάνονται ότι δεν πρόκειται για το ίδιο με το οποίο έγιναν compile και για λόγους security το απορρίπτουν.

Δοκίμασε μέσω του App.Config να κάνεις bind σε παλαιότερη version του assembly μέσω του BindingRedirect.

---

Vir prudens non contra ventum mingit

Kelman, σ' ευχαριστώ για την απάντηση, αλλά το πρόβλημα εμφανίζεται στο deserialization μόνο. Κατά τ' άλλα, το πρόγραμμα λειτουργεί κανονικά, και τα updates ανανεώνουν όλα τα .dlls.

Πιο συγκεκριμένα, αν κάνω serialize ένα αντικείμενο σε assembly έκδοσης 1.0.0.1 και το στείλω μέσω Sockets σε ένα άλλο application που έχει το assembly έκδοσης 1.0.0.0, θα χτυπήσει με... FileNotFoundException όταν πάει για το Serialize (το assembly αυτό χρησιμοποιείται και σε πολλούς άλλους τομείς των προγραμμάτων και των Services χωρίς πρόβλημα).

Εγώ θέλω να συγκρίνει τους τύπους που γίνονται deserialized, και το αν αυτοί εκφράζονται σωστά από την τρέχουσα έκδοση. Το FormatterAssemblyStyle λύνει αυτό το πρόβλημα (γιατί δεν έχω χρόνο και διάθεση να ασχοληθώ με το ISerialize);

Αν δε βρω κάποια άκρη, θα χρησιμοποιήσω τη συμβουλή σου Kelman.

---

Μην αφήνετε τα media να σας "ταΐζουν"!

Λοιπόν, βρήκα το πρόβλημα (ή πιο σωστά, το βρήκε κάποιος άλλος για μένα): http://lab.msdn.microsoft.com/ProductFeedback/viewFeedback.aspx?feedbackid=b08b64df-49f2-44a3-ac10-7811281eb149

Φαίνεται πως υπάρχει κάποιο πρόβλημα με το VTS και τη χρήση Generic types. Μια λύση η οποία φαίνεται να δουλεύει μέχρι να βγει το κατάλληλο SP, είναι να απαλείψω εντελώς το AssemblyVersion attribute από το referenced component!

---

Μην αφήνετε τα media να σας "ταΐζουν"!