[Σε συνέχεια του Μετάβαση σε VS 2005: Περιπέτεια!]
Στο Visual Studio 2003 τα web projects είχαν παρόμοια δομή με τα win projects. Υπήρχε ένα αρχείο για το ίδιο το project (vbproj, csproj) το οποίο περιέγραφε ποια αρχεία ήταν μέρος του project.
Στο 2005 το μοντέλο αλλάζει. Αρχείο για το project δεν υπάρχει, αντιθέτως θεωρούνται μέρος του projects όλα τα αρχεία που βρίσκονται στον δίσκο στον κατάλογο ο οποίος αντιστοιχεί στο web project. Αυτό σημαίνει, ότι όποιο αρχείο και αν προσθέσουμε από file system στον κατάλογο αυτόν ή στους υποκαταλόγους του, αυτομάτως θεωρείται μέρος του web project.
Ας έρθουμε τώρα στο source safe, όταν το web project είναι source controlled. Όλα τα αρχεία που υπάρχουν στον δίσκο, αφού είναι μέρος του project, προστίθενται αυτομάτως στο VSS. Μοναδική εξαίρεση αποτελούν οι DLLs και τα PDB αρχεία τα οποία προέρχονται από project references (προσοχή, μόνο project references, όχι file references που έχουν copy local = true).
Με το μοντέλο αυτό παρουσιάζει το εξής σημαντικό πρόβλημα:
Web project χωρίς κώδικα μέσα. Για παράδειγμα ένα web project που κάνει expose στον έξω κόσμο web services (asmx αρχεία) τα οποία κληρονομούν web services κλάσεις που βρίσκονται σε άλλα class libraries. Σε αυτή την περίπτωση, αφού δεν υπάρχει αρχείο για το web project και άρα δεν υπάρχει μέρος να καταγραφούν τα referenced projects του web project, ναι μεν φέρνει μέσα τις dlls των class libraries (κοιτάζοντας το inherit μέσα στα asmx), αλλά τις αντιμετωπίζει σαν file references και όχι σαν project references, αφού δεν υπάρχει κώδικας στο web project που να αναφέρεται σε κώδικα άλλων projects από το ίδιο solution. Ως αποτέλεσμα, στο check in του solution κάνει add τις dlls και τα pdb αρχεία δημιουργώντας προβλήματα στα builds γιατί αυτό κάνει τα αρχεία readonly.
Ένα workaround είναι να σβηστούν οι dlls και τα pdb που έχουν έρθει, να δημιουργηθεί μια dummy class μέσα στο web project η οποία να περιέχει στοιχειώδεις αναφορές σε όλα τα web projects που θέλουμε να γίνουν referenced με project references, και μετά να ξαναβάλουμε project references, τα οποία πλέον θα κρατήσει.
Με το workaround αυτό όμως παραμένει το εξής πρόβλημα: Δεν μπορούμε να έχουμε web projects τα οποία ανήκουν σε άλλο solution για τα οποία να έρχονται και οι dlls και τα pdb αρχεία (για να συμμετέχουν στο debugging του web project). Αν ανήκουν σε άλλο solution, σε καμία περίπτωση δεν μπορούν να αντιμετωπιστούν σαν project references, άρα μόλις έρθουν τα pdbs στο επόμενο checkin θα γίνουν add στο VSS και θα κλειδωθούν.
Το σενάριο που περιγράφω είναι κλασσικό για smart clients. Από την μία, απ' όσο τουλάχιστον διαβάζω τις τελευταίες μέρες σε διάφορα microsofτικά forums, το studio δεν έχει φτιαχτεί για να δουλεύεις με 20 μεγάλα projects στο ίδιο solution, και από την άλλη η δομή του σε υποχρεώνει να έχεις όλα τα project στο ίδιο solution από τα web services και πίσω (αν θέλεις να έχεις debugging βέβαια).
Η φιλοσοφία δε, του τελειώνουμε ένα χαμηλά στα dependencies project, κάνουμε τρελή αποσφαλμάτωση, είμαστε απολύτως σίγουροι ότι δουλεύει σωστά, το κάνουμε compile σε dll και δεν το ξαναγγίζουμε, δεν φαίνεται ικανοποιητικά πραγματοποιήσιμη στην ελληνική ρεαλιστική αγορά.
Είμαι πάντως πολύ περίεργος να μάθω πως δούλεψαν όλοι αυτοί οι μεγάλοι οργανισμοί και εταιρίες που έδειχνε η Microsoft στο Launch Event. Είχαν άραγε παλιά projects τα οποία έκαναν convert από τις beta ακόμα; Πως πλανάρανε τα resources τους; Τι μεγέθους projects δουλεύουν; Γιατί, εμένα μου δόθηκε η εντύπωση ότι αυτοί οι οργανισμοί / εταιρίες κολοσσοί, είχαν τεράστια projects άξια αναφοράς, τα οποία γύρισαν σε VS 2005 κάποια στιγμή από τις beta, και στις αρχές Δεκεμβρίου είχαν ήδη προϊόν που έτρεχε. Τι προβλήματα αντιμετώπισαν; Ποιες είναι οι προτεινόμενες πρακτικές; Δεν ξέρω, πολλά τα ερωτήματα και λίγες οι απαντήσεις...