views:

97

answers:

2

This is easily one of the most annoying "features" of Visual Studio in its history and I don't understand why it exists -- ever.

Why would a CodePlex project need to care what version of Visual Studio I am using?

Off the top of my head, the only thing I can think of is that some versions of Visual Studio might introspect assemblies searching for attributes to determine what to display in "Visual Designers" and "Property Editors". But why would that cause Visual Studio to not be able to open the project and allow me to browse its contents and compile?

It seems to me like Open Source in .NET is somewhat limited by the stupid dependency management exhibited by Visual Studio. In other words, if I am using Visual Studio 2008 and you are using Visual Studio 2010, then we have different solution files.

+1  A: 

I believe the purpose of this touches on what you stated in your comments. If you are using 2008 and I 2010 and I compile it, how could you possibly run it again? 2010 is backwards compatible but 2008 has no way to make itself forward compatible.

Thus, by recompiling the project in 2010 I ensure that no 2008 user may mistakenly think they can compile it.

Michael Eakins
_@Meakins_, your answer seems to beg the question: What you're saying is that VS solutions are version-specific so that solutions are incompatible across different versions?
stakx
I am saying that there is no way to make a program look forward and know what will be needed in the next build or version everytime. Solutions are incompatible across different versions as the poster of this question has pointed out.
Michael Eakins
@Meakins: However, you aren't explaining why VS2010 can't work as is with VS2008 solution files, or why VS2010 can't save VS2008 solution files.
David Thornley
So you down vote me for answering the question? I suggest you read the asnwers rather than judging them based on what you perceive we are saying.
Michael Eakins
@Meakins: I downvoted you for not answering the question. You blatantly assume that a project compiled in 2010 cannot be used in 2008, while the question was why that is the case.
David Thornley
@Meakins: I think David is expecting the answer to be a list of what tools were changed and why those specific tools were changed, rather than accepting the fact that the change occurred. VS 2008 can't open VS 2010 solutions because things such as Resource Editors, Modelling tools, etc. are different in 2010. It is out of the scope of the question to expect a listing of every tool that has been changed and why that specific tool was changed.
myermian
@Meakins: It seems to me that the IDE is too deeply involved if projects that don't have dependencies on fancy IDE tools can't interoperate across versions of Visual Studio. In a nutshell, Visual Studio has poor handling of dependencies. It might be interesting to see how this compares to a modular, even if bloated, IDE like Eclipse. Eclipse is the most common IDE for open source Java.
+1  A: 

http://blogs.msdn.com/b/visualstudio/archive/2010/03/15/why-does-visual-studio-2010-convert-my-projects.aspx

Here's an example from the site as to why Visual Studio converts your projects to 2010 format.

For instance, Visual Studio runs custom tools such as single file generators for designers in order to output code representing the changes made to the designer. Many of these custom tools are upgraded or completely replaced in the newer IDE. During conversion, the IDE knows which custom tools to replace or upgrade. In order to make round-tripping work, VS would need old and new custom tools to understand each other so as to ensure that old and new designers can work side by side. Other than designers, the following files would also be affected: resource editors, wizards, code snippets, item and project templates, diagramming and modeling tools, and many more.tools, and many more.

Since 2010 knows about what tools 2008 has, it can convert forward to be compatible with the custom tools 2010 uses. 2008 has no idea about what 2010 is using, how could it? Therefore, it is impossible to convert backwards since it doesn't know what it needs to convert, nor how to.

myermian
No, it's not impossible to convert backwards. It's impossible for VS 2008 to convert backwards. It's very possible for VS 2010 to convert backwards, perhaps warning of possible information loss.
David Thornley
I voted you back up @myermian as @David Thornley is obviously not reading the response.
Michael Eakins
@Meakins: I did read the response. The blog post explained that there are custom tools, which change between versions for no actually explained reason. It then falsely stated it would be necessary for old and new tools to understand each other, when all that is necessary is for new tools to understand the old file format. The final paragraph simply repeats the blog excerpt with fewer words, and concludes that since VS2008 cannot do the conversion, it's impossible. Would you care to either dispute my comprehension in detail or retract your statement about me?
David Thornley
It cannot be compiled in 2008 after being compiled in 2010!
Michael Eakins
@Meakins: Now read the OP's question. It is, essentially, "Why did Microsoft do X?" Your answer above is "X!". All of us know that X is true, and your repetitions add nothing to the discussion. What the OP wants to know is why X is the case. If you have some insight on that, please share it. In the meantime, you might want to read the responses on that blog post.
David Thornley
@David Thornley: I'm not sure what is misleading about that blog posting. It is obviously stating that Microsoft uses different tools in VS 2010 than in VS 2008. VS 2010 knows how to convert from 2008 to 2010 since those tools are known. VS 2008 does not know about the tools VS 2010 is using, so it can't do that conversion. "Why do Visual Studio solutions need to be upgraded with every release of Visual Studio?" because Microsoft makes changes to those tools. If the OP wants to know specifics about what tools were changed and what enhancements came from them, he can ask that.
myermian
@myermian: What's misleading about the blog post is that it implicitly claims that different tools need different formats and cannot do backward conversions. Clearly, VS2010 tools will do somewhat different things than VS2008 tools. Presumably, some information from VS2010 tools isn't in VS2008 file formats. That doesn't mean that there can't be full round-trip compatibility, 08->10->08 (the other way is more of a problem). The lack isn't an inherent property of development systems, so Microsoft either didn't want round-trip or designed things in a way that made it too expensive.
David Thornley
@David Thornley - I believe what you are saying is true. Micorsoft likely didn't want to spend the extra time and/or cash to make it round-tripable.
Michael Eakins
@myermian: Thanks, that is exactly what I was looking for! I am dissatisfied with the answer (I think the blog post you linked paints the problem as black-and-white), but at least it is good to know MS has a position on this.
@user429921: The nice thing is that they are hinting at having this "round-trip" become available on the next release.
myermian
thanks for that tip. where is your source?
@user429921 - The same article.
myermian