Thanks for the answer.

I think we haven't understood each other well, so let me rephrase :
- the vcproj and csproj project file formats pay a different attention to references components, for instance when you insert an ActiveX component onto a dialog (C++) or a form (C#). The vcproj project file won't even keep track of whether an ActiveX has been added, leaving plenty of rooms for deployment issues. The csproj project, however, keeps track of the ActiveX (Build / References / Reference / guid= ...), essentially because it has to use a combination of tlbimp and aximp in order to interop the type-library before it's seen like a regular assembly. At this point, the question is : why do the two projects have a different view on those references? The language you are using does not change anything to the fact that an ActiveX has to be preinstalled on the client machine in order for the app to work, regardless it's written with C++ or C#, so using C++ in this example maximizes the potential of deployment issues, right?
- Wasn't the overhaul of the file formats a chance to solve that kind of issues, and provide consistency across file formats? Quite honestly, I don't understand. Microsoft has been changing the file format in 7.0, 7.1 and is probably changing it again in Whidbey (msbuild, ...), but I am not sure at all that it solves the typical developer issues that we face, especially deployment.
- if you insert an ActiveX component into a .rc dialog, then the clsid of that ActiveX is referenced there. Unfortunately, this clsid is only taken care of at run-time when the dialog loads the controls, and the app will fail miserably if the clsid does not exist. Why isn't there a dependency checker at design-time? That said, why isn't the prog id referenced and used instead or as well of the clsid? Isn't the independent version progid meant to solve deployment and versioning issues? Why isn't VS.NET helping developers in this regard? Let's take an example : I develop a sample app using Windows Media player 6.4, and it runs on Windows 2000. Now I want this app to work on Windows XP. How can I know whether the app works at all? If the app references an independent version progid, then even if Windows XP does not have Windows Media player 6.4 preinstalled, it can start say Windows Media player 8.0, so my app works. But if we use clsids, chances are the app works only on Windows 2000.
- regarding shared paths. You have mentioned relative paths (hintpath), that's right. But because you have also said it's not possible to use macros on the one hand, and there is no direct support for that in the IDE, then it's simply not possible to do teamwork, unless you are in a special case : all source code under a single branch tree (is that realistic and fair?). Indeed, the relative paths raises issues as soon as my branch is installed on say C:\Dev and not the whole source code is put in subfolders, while my coworker's branch is D:\Version5\Source. Files references with relative paths will be ok on my machine, not his, and vice versa. The question is : have you introduced anything in Whidbey to solve this or at least try? clsids?

PingBack from http://insomniacuresite.info/story.php?id=5068