josh's WebLog

Visual C++ IDE from the trenches

feedback on Stephane's comments: activex controls, references, deployment

Stephane has responded with some cogent observations and questions, see the feedback to my response yesterday. let's see if i can (briefly) cover the issues he brings up one at a time:

first off, the handling of managed references to activex controls and the differences between how they are handled in c# and vc project systems. to be clear, managed projects referencing activex all treat them the same way, it is native c++ projects that function differently. in managed projects the CLSID for the control is stored in the project file, while in native projects it is not. this is due entirely to the fact that managed projects need the guid in order to build the project and native ones do not. neither project system attempts to use the project file as a repository for deployment information. in fact, deployment is not handled in VS by the language project systems at all, but rather by setting up separate deployment projects. (i won't comment on deployment projects, since i have nothing nice to say).

project file formats really has nothing to do with any of the above. there was never an intention to provide deployment information in the project file itself.

progid, clsids and versioning: there is no correct answer to the COM versioning question(s) and the project system doesn't even try to provide one; if it did, it would always be wrong for some set of customers. some apps would prefer to pick up any version of a control, for instance, while others are tied to a very specific version. COM versioning is a very complex issue, this is one of the prime motivations behind .NET (not that it really solves the issues, if you ask me). what we try to do in the vc project system is to give the developer the flexibility to do what they think is best. if there are ways we can get closer to that goal, we'd love to hear about them.

finally, regarding reference paths and sharing. yes, Stephane, i think you have picked up on exactly what i was saying about references: they aren't designed to be shareable in a flexible manner. hence my recommendation against using them in 2003 unless absolutely necessary. we in VC are certainly trying to improve the situation in whidbey. i can't speak for the c#/vb/j# project system.
Published Tuesday, February 10, 2004 5:33 PM by josh_

Comments

 

Stephane Rodriguez said:


Thanks for your answer. While I understand the design choices, I still disagree with "there was never an intention to provide deployment information in the project file itself."

While a makefile is traditionally only been used to manage the compilation/linking phase, and thus not the deployment task, I think that :
- it's not the way MSBuild is going. After all, the CSharp.targets file has many more tasks other than compiling and linking, and those include the dependency checking as well as the setup building tasks. I am trying to guess the consistency between where VS.NET 2002 and 2003 are today, and what MSBuild will lead people to. I don't understand why there has been such a great missed opportunity (smooth change) when the .dsw/.dsp files were made legacy and replaced with much more versatile and declarative xml. In the PDC, MSBuild was said to be a way to expose the underlying VS.NET solution/project infrastructure. I think it's overstated. The goals are different.
- software companies write automated build systems. Microsoft doesn't provide anything to date to ease this, software companies have to write it themselves, right? An automated build system is really a necessary step and is what matters most for the project management, not the compiling of some file or another (understand me well here). I am quite surprised that even though Redmond could help software companies and avoid them to write their own automated build systems, which is a development task that is costly, lengthy and cumbersome, there is no feeling that the way VS.NET project files are architectured to cope with this real-world use.
- Last but not least, MS Reporting Services (integrated with VS.NET as you probably know) builds solutions and deploys them. At some point, the lack of consistency between VS.NET integrated "compilers", the lack of taking care of dependencies and the deployment phase in a transversal manner is going to hurt.
- in short, since the process of compiling/linking source code is only part of a broader development process with more general purposes, anything towards simplifying development issues is welcome.
February 11, 2004 6:31 AM
Anonymous comments are disabled

This Blog

Syndication

Tags

No tags have been created or used yet.

© 2009 Microsoft Corporation. All rights reserved. Terms of Use  |  Trademarks  |  Privacy Statement
Microsoft
Page view tracker