Visual Studio 2008 released

[Jon Skeet [C# MVP]]

Ah. Maybe a browser bug. I'm using Mac Safari. I loaded the page in
Mac Opera and it looks fine.

<snip>

Ironically I've only recently started using "div" for this sort of
thing, precisely because I couldn't get my previous mechanism (using
tables) to look nice on both IE and Firefox... and now Safari isn't
coping!

I think I'd be more worried if Mac users were likely to be part of my
main demographic. Google Analytics (running on my home page; I can't
get it to work on my blog for some reason) shows Safari at only 0.63%
of hits. It's very annoying though - but at least I know, in case
someone asks...

Jon

 

[Willy Denoyette [MVP]]

But presumably that should stop it from compiling C# 3 code, which is
what I meant - sorry.


Mmm... doesn't seem to be doing anything on my machine

Unless that's interacting with the difference between MSBuildToolsPath
and MSBuildBinPath...

Jon,
Here's the output of a rebuild of a VS2008 solution containing two projects:
1. is a VS2008 project (wftaT1) targeting V3.5
2. is a VS2005 project (volsvs) added to the VS2008 solution.
In project 2, I changed ToolsVersion= "3.5" into "2.0", so now the first
line of .csproj looks like this:
<Project DefaultTargets="Build"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003"
ToolsVersion="2.0">
------ Rebuild All started: Project: wfaT1, Configuration: Debug x86 ------

C:\Windows\Microsoft.NET\Framework\v3.5\Csc.exe /noconfig /nowarn:1701,1702
/platform:x86 /errorreportrompt /defineEBUG;TRACE /reference:"C:\Program
Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\System.Core.dll"
/reference:"C:\Program Files (x86)\Reference
Assemblies\Microsoft\Framework\v3.5\System.Data.DataSetExtensions.dll"
/reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Data.dll
/reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Deployment.dll
/reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.dll
/reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Drawing.dll
/reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Windows.Forms.dll
/reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll
/reference:"C:\Program Files (x86)\Reference
Assemblies\Microsoft\Framework\v3.5\System.Xml.Linq.dll" /debug+ /debug:full
/filealign:512 /outbj\x86\Debug\wfaT1.exe
/resourcebj\x86\Debug\wfaT1.Form1.resources
/resourcebj\x86\Debug\wfaT1.Properties.Resources.resources /target:winexe
/win32manifest:app.manifest Form1.cs Form1.Designer.cs Program.cs
Properties\AssemblyInfo.cs Properties\Resources.Designer.cs
Properties\Settings.Designer.cs

Compile complete -- 0 errors, 0 warnings

wfaT1 -> E:\Develop\VS2008Proj\wfaT1\wfaT1\bin\x86\Debug\wfaT1.exe

------ Rebuild All started: Project: volsvs, Configuration: Debug Any
CPU ------

C:\Windows\Microsoft.NET\Framework\v2.0.50727\Csc.exe /noconfig
/nowarn:1701,1702 /platform:x86 /errorreportrompt /warn:4
/defineEBUG;TRACE
/reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Data.dll
/reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.dll
/reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll
/debug+ /debug:full /optimize- /outbj\Debug\volsvs.exe /target:exe
Program.cs Properties\AssemblyInfo.cs

Compile complete -- 0 errors, 0 warnings

volsvs -> E:\Develop\vs2005proj\volsvs\volsvs\bin\Debug\volsvs.exe

========== Rebuild All: 2 succeeded, 0 failed, 0 skipped ==========



See, the project (1) is build using csc.exe V3.5 (C# 3), while for (2),
csc.exe is V2.

The great thing here is that you can mix project versions, you can change
project settings from within the VS2008 IDE, the "ToolsVersion" will not be
touched.
Things to keep in mind when setting the ToolsVersion="2.0", are:
- the project file does not become a true VS2008 project file, it remains an
imported project file, and
- CSC V2 does/can not add a manifest to the resulting exe (for exe targets),
this is a problem when targeting Vista and W2K8. You should never run
manifest-less applications on Vista and up, so, here you'll have to add a
manifest by running mt.exe after each build.

Willy.

 

[Marc Gravell]

By adding the ToolsVersion (to avoid the upgrade) I get similar output
(framework 2.0.blah of csc) - however, it also compiles perfectly
happily with C# 3 code - i.e. "var test = 2;", and in a team scenario
that isn't going to work well with colleagues who haven't upgraded
yet.

So it may well be using the 2.0 versions of the satellite tools get
used, but at the core it is using the C# 3 compiler even though it
uses csc 2.0... I don't know how or why...

Marc

 

[Marc Gravell]

And even more bizarrely, if I copy the command-line from the
*successful* build output (including the path with framework 2.0) and
execute directly, then I get a CS0246 (The type or namespace 'var'
could not be found...).
Maybe some environment variable?

Marc

 

[Marc Gravell]

**warning**
One of my test-rigs here was VS2008 only, and while it /worked/ with
the 2.0 flag, it raised a silent warning about not being able to find
the 2.0 SDK path. So I thought "what the heck, lets install the 2.0
SDK".

VS2008 did not like that very much ;-(

Oh well, it only takes a couple of hours to reinstall... and I have
other rigs...

Marc

 

[Willy Denoyette [MVP]]

By adding the ToolsVersion (to avoid the upgrade) I get similar output
(framework 2.0.blah of csc) - however, it also compiles perfectly happily
with C# 3 code - i.e. "var test = 2;", and in a team scenario that isn't
going to work well with colleagues who haven't upgraded yet.

So it may well be using the 2.0 versions of the satellite tools get used,
but at the core it is using the C# 3 compiler even though it uses csc
2.0... I don't know how or why...

Marc

Ok, forget about this "ToolsVersion" thing, VS doesn't use the command line
compilers at all. VS loads the CS language services "... \Microsoft Visual
Studio 9.0\VC#\VCSPackages\cslangsvc.dll" in devenv.exe, the CSC output
message is kind of bogus. That means that whatever you do, VS will always
use the latest "compiler", that means that you can't rely on the compiler to
detect C# 3 feature usage in projects that target V2 or V3 projects.

Willy.

 

[Jon Skeet [C# MVP]]

On Nov 21, 1:39 pm, "Willy Denoyette [MVP]"

Ok, forget about this "ToolsVersion" thing, VS doesn't use the command line
compilers at all. VS loads the CS language services "... \Microsoft Visual
Studio 9.0\VC#\VCSPackages\cslangsvc.dll" in devenv.exe, the CSC output
message is kind of bogus. That means that whatever you do, VS will always
use the latest "compiler", that means that you can't rely on the compiler to
detect C# 3 feature usage in projects that target V2 or V3 projects.

Okay, so at least we know why it wasn't working then. Glad it wasn't
just me.

As I mention in the blog post, you *can* stop the compiler from using
C# 3 features, but not in a way which works with 2005 - if you specify
a LangVersion of "ISO-2" it will give nice error messages in VS2008,
but not recognise it as a valid value in VS2005

Jon

 

[Marc Gravell]

Cheers for the info. If nothing else, it'll stop me from wasting time
trying ;-p

Marc

 

[Willy Denoyette [MVP]]

On Nov 21, 1:39 pm, "Willy Denoyette [MVP]"



Okay, so at least we know why it wasn't working then. Glad it wasn't
just me.

As I mention in the blog post, you *can* stop the compiler from using
C# 3 features, but not in a way which works with 2005 - if you specify
a LangVersion of "ISO-2" it will give nice error messages in VS2008,
but not recognise it as a valid value in VS2005

Jon

It's getting messy isn't it? When installing VS2008 on a 64 bit system that
has VS2005 SP1 installed, you'll end with a system that has:

- The framework command line compiler version 8.00.50727.1433 (C# 2.0) for
2.0.50727 of the framework, note that this is the compiler that comes with
SP1 of the Framework!
- The framework command line compiler "version 3.5.21022.8" (C# 3.0) for
version 3.5 of the framework.
The same as above, but in a 64-bit version (you have separate Frameworks
tools for 32 and 64 bit).

- The VS2008 compiler "components" version 3.5.21022.8 (C# 3.0).
- The VS2005 compiler "components" 8.00.50727.0762 (C# 2.0) (SP1 of VS2005!)

Note that for VS there is only one set of compiler components (one per
version), VS is 32 bit code so are the components (DLL's).
We know by now that VS2008 builds exclusively using 3.5.21022.8 (C# 3.0)
components, there is no way to use 8.00.50727.1433 from within the IDE.
VS2005 uses 8.00.50727.0762 (C# 2.0) of the compiler components. That all
means that we cannot build a project using the compiler version
8.00.50727.1433 , that is SP1 of the framework using VS.
This scares me a bit, especially when you know that a number of compiler
bugs may have been corrected in the SP1 binaries. I definitely would like to
see a list of the bugs corrected in SP1 of the framework.

Willy.

 

[Peter Duniho]

Ironically I've only recently started using "div" for this sort of
thing, precisely because I couldn't get my previous mechanism (using
tables) to look nice on both IE and Firefox... and now Safari isn't
coping!

I didn't look at the CSS where "code" is defined, but it may be there's
some property that's specifically causing the problem and which could
be implemented some other way. Or possibly it has to do with the
broader layout of the page (such as the other section to the left)
that's causing a Safari bug to manifest itself.

I have successfully used similar techniques in a way that's compatible
with Safari, so I can at least say that it's not the "div" itself
that's causing the problem per se.

I think I'd be more worried if Mac users were likely to be part of my
main demographic. Google Analytics (running on my home page; I can't
get it to work on my blog for some reason) shows Safari at only 0.63%
of hits. It's very annoying though - but at least I know, in case
someone asks...

Do your metrics tell you whether that's Mac Safari or Windows Safari?
Or does it lump it all into the same category? Does it tell you the
version?

I'm using Safari 2, though I've been thinking about upgrading to 3 now
that it's had a bit of public wringing out (it had a bunch of bugs,
including security flaws, when it was first released). Maybe the
latest version works better (Safari doesn't handle MSDN's web site very
well either, failing to display the navigation pane properly).

At 0.63%, I think it's possible that I am the only user out of a couple
hundred that visit the blog who is using Mac Safari. If your
unique visitors numbers more in tens of thousands or greater, then
frankly I find 0.63% to be quite high...there are more masochists out
there than I might have thought.

In any case, I have never been a fan of going to much effort to work
around bugs in third-party software. There a certain situations where
it's required, but I'd say in this case there's no reason for you to
put any additional effort into getting things to look right on Safari.
You could spend quite a lot of time working around bugs in that browser
if you're so-inclined.

Pete

 

[Jon Skeet [C# MVP]]

I didn't look at the CSS where "code" is defined, but it may be there's
some property that's specifically causing the problem and which could
be implemented some other way. Or possibly it has to do with the
broader layout of the page (such as the other section to the left)
that's causing a Safari bug to manifest itself.

Here's the css for code/output:

div.code, div.output
{
border-right: white 2px ridge;
padding-right: 10px;
border-top: white 2px ridge;
padding-left: 10px;
font-size: 10pt;
padding-bottom: 10px;
margin: 10px;
border-left: white 2px ridge;
padding-top: 10px;
border-bottom: white 2px ridge;
font-family: courier new;
background-color: #e5e5e5;
display: table-cell
}

My *guess* is that it's the display: table-cell that's causing grief,
but I don't know.

I have successfully used similar techniques in a way that's compatible
with Safari, so I can at least say that it's not the "div" itself
that's causing the problem per se.



Do your metrics tell you whether that's Mac Safari or Windows Safari?
Or does it lump it all into the same category? Does it tell you the
version?

A different report shows me the breakdown there:

0.51% Mac/Safari (334 visits)
0.09% Windows/Safari (60 visits)

I know that doesn't add up to 0.63%...

It doesn't give me different versions.

I'm using Safari 2, though I've been thinking about upgrading to 3 now
that it's had a bit of public wringing out (it had a bunch of bugs,
including security flaws, when it was first released). Maybe the
latest version works better (Safari doesn't handle MSDN's web site very
well either, failing to display the navigation pane properly).

It's just about possible

At 0.63%, I think it's possible that I am the only user out of a couple
hundred that visit the blog who is using Mac Safari. If your
unique visitors numbers more in tens of thousands or greater, then
frankly I find 0.63% to be quite high...there are more masochists out
there than I might have thought.

Just to be clear, this is my "normal website" rather than my blog. I
don't believe

In any case, I have never been a fan of going to much effort to work
around bugs in third-party software. There a certain situations where
it's required, but I'd say in this case there's no reason for you to
put any additional effort into getting things to look right on Safari.
You could spend quite a lot of time working around bugs in that browser
if you're so-inclined.

Indeed. To be honest, I have so little time that "works on IE and
Firefox" is good enough - and even on Firefox my blog doesn't look
great, with the inline code font being pretty small

 

[Liz]

<http://msmvps.com/blogs/jon.skeet/archive/2007/11/20/vs2005-and-vs2008-co-existence.aspx>

thanks, Peter .... and Chris S .... and Jon ....

I downloaded and installed Wireshark; now I know how much I know about
networking .. it's depressing ....


that aside, do you have to explicitly UNINSTALL VS 2005 before installing VS
2008 or does the installer handle all of that for you?

 

[Peter Duniho]

[...]
My *guess* is that it's the display: table-cell that's causing grief,
but I don't know.

It is. For what it's worth, it should display just fine without the
"display" property. I did a simple test by copying the HTML and style
sheet locally and taking it out, and it fixed the display problem on
Safari, and otherwise looked fine.

It's not clear to me from the document structure whether you actually
have control over the CSS or not, but if you do that would be something
you could change to fix the issue.

[...]
A different report shows me the breakdown there:

0.51% Mac/Safari (334 visits)
0.09% Windows/Safari (60 visits)

I know that doesn't add up to 0.63%...

Heh, no kidding. It's not even close enough to just blame on round-off error.

Things that make you go "hmmm". )

[...]
At 0.63%, I think it's possible that I am the only user out of a couple

hundred that visit the blog who is using Mac Safari. If your
unique visitors numbers more in tens of thousands or greater, then
frankly I find 0.63% to be quite high...there are more masochists out
there than I might have thought.

Just to be clear, this is my "normal website" rather than my blog. I
don't believe
Yes?

Indeed. To be honest, I have so little time that "works on IE and
Firefox" is good enough - and even on Firefox my blog doesn't look
great, with the inline code font being pretty small

Yeah, it's always bugged me that all of the browsers I've used handle
font sizes differently. Grrr.

It's possible you can work around that by specifying the size in
different units (e.g. pixels instead of points). Again, I've never
really cared enough to bother playing with it.

Pete

 

[Jon Skeet [C# MVP]]

that aside, do you have to explicitly UNINSTALL VS 2005 before installing VS
2008 or does the installer handle all of that for you?

You don't need to uninstall 2005 at all - you can run the two side by
side.

You *do* need to uninstall any 2008 betas, however.

 

[Jon Skeet [C# MVP]]

[...]
My *guess* is that it's the display: table-cell that's causing grief,
but I don't know.

It is. For what it's worth, it should display just fine without the
"display" property. I did a simple test by copying the HTML and style
sheet locally and taking it out, and it fixed the display problem on
Safari, and otherwise looked fine.

It's not clear to me from the document structure whether you actually
have control over the CSS or not, but if you do that would be something
you could change to fix the issue.

I do have control over that. The reason for the display property is to
make the box only extend as far as the text, rather than all the way to
the right. I'll have a look tonight.

[...]
At 0.63%, I think it's possible that I am the only user out of a couple

hundred that visit the blog who is using Mac Safari. If your
unique visitors numbers more in tens of thousands or greater, then
frankly I find 0.63% to be quite high...there are more masochists out
there than I might have thought.

Just to be clear, this is my "normal website" rather than my blog. I
don't believe

Yes?

No idea!

Yeah, it's always bugged me that all of the browsers I've used handle
font sizes differently. Grrr.

It's possible you can work around that by specifying the size in
different units (e.g. pixels instead of points). Again, I've never
really cared enough to bother playing with it.

Unfortunately I believe that part is to do with some CSS that I *don't*
have control over. It's certainly not a problem in my normal website

 

[Chris Nahr]

It's getting messy isn't it? When installing VS2008 on a 64 bit system that
has VS2005 SP1 installed, you'll end with a system that has:

Willy, since you're apparently running VS2008 on Vista 64 perhaps you
can tell me what's up with item 2.3.1.2 in the ReadMe file:

2.3.1.3. Locals window does not work on the 64-bit version of Windows Vista.
The Locals window is not visible when Visual Studio is running on the 64-bit version of Windows Vista.

To resolve this issue:
No workaround is available.

Does this really mean there's no Locals window in the VS2008 debugger?
As in, you cannot examine any local variables? That would be a reason
to put off the upgrade until this is fixed.

Apologies for hijacking this thread -- I've asked this question here
and on the MSDN forums but have not received any answers to what
strikes me as a very important question.

 

[Willy Denoyette [MVP]]

Willy, since you're apparently running VS2008 on Vista 64 perhaps you
can tell me what's up with item 2.3.1.2 in the ReadMe file:


Does this really mean there's no Locals window in the VS2008 debugger?
As in, you cannot examine any local variables? That would be a reason
to put off the upgrade until this is fixed.

Chris,

I fail to see where this comes from, but the "Locals" window is there and
you can drill down the locals as expected. Don't know this is true for a
project types, but it works on Vista 64 for all kind of Csharp projects.

Willy.

 

[Chris Nahr]

Chris,

I fail to see where this comes from, but the "Locals" window is there and
you can drill down the locals as expected. Don't know this is true for a
project types, but it works on Vista 64 for all kind of Csharp projects.

Willy.

Thanks, that's what I wanted to know! I was quoting from the file
Readme.htm that is located in the root directory of the downloadable
RTM ISO for the VS2008 Professional edition. See for yourself, it's
the third item under "General Issues".

 

[Willy Denoyette [MVP]]

Thanks, that's what I wanted to know! I was quoting from the file
Readme.htm that is located in the root directory of the downloadable
RTM ISO for the VS2008 Professional edition. See for yourself, it's
the third item under "General Issues".

Chris,
Well, I know where to find the quote, sorry for the confusion , but I
don't know where the author of the Readme got this from, maybe something
that wasn't working in one of the beta's, anyway it definitely works in the
Release version.

Willy.

 

[Peter Duniho]

I do have control over that. The reason for the display property is to
make the box only extend as far as the text, rather than all the way to
the right. I'll have a look tonight.

Ah. I guess beauty's in the eye of the beholder, but personally, I'd
prefer all the inline boxes to be the same width. Whether they are all
exactly the width of the layout box in which they're contained or some
specific proportion is less important, but especially where you have
several close to each other I think consistent widths would look nicer.

[...]
It's possible you can work around that by specifying the size in

different units (e.g. pixels instead of points). Again, I've never
really cared enough to bother playing with it.

Unfortunately I believe that part is to do with some CSS that I *don't*
have control over. It's certainly not a problem in my normal website

Well, the font size is defined in the same class where you set the
"display" property for inline code. So obviously you could change it
there.

I assume you're saying that there's actually something else in the CSS
that's interacting negatively with the font size defined for
"div.code". About that, I have no ideas.

Pete