Visual C++ Tools Refresh ready today

[Brandon Bray [MSFT]]

Shortly, the Visual C++ Tools Refresh will be available on the MSDN Visual
C++ devcenter. You will need to have installed the Visual Studio 2005 Beta
first. <http://msdn.microsoft. com/visualc>

I have been talking about this a lot over the last two months. All of the
features that are missing in the compiler for Beta 1 are now available in
the tools refresh. These refreshes are builds out of live development branch
and thus are not thoroughly tested. We do maintain high quality goals during
development, so these are useful for testing.

I'm looking forward to your feedback.

--
Brandon Bray, Visual C++ Compiler http://blogs.msdn.com/branbray/
This posting is provided AS IS with no warranties, and confers no rights.

[Thomas Scheidegger [MVP]]

> Shortly, the Visual C++ Tools Refresh will be available

thanks, here we go:

http://www.microsoft.com/downloads/d...e-e13eb0341923
http://download.microsoft.com/downlo...09_install.exe

--
Thomas Scheidegger - MVP .NET - 'NETMaster'
http://www.cetus-links.org/oo_dotnet.html - http://dnetmaster.net/

[Carl Daniel [VC++ MVP]]

Brandon Bray [MSFT] wrote:

Shortly, the Visual C++ Tools Refresh will be available on the MSDN
Visual C++ devcenter. You will need to have installed the Visual
Studio 2005 Beta first. <http://msdn.microsoft. com/visualc>

I have been talking about this a lot over the last two months. All of
the features that are missing in the compiler for Beta 1 are now
available in the tools refresh. These refreshes are builds out of
live development branch and thus are not thoroughly tested. We do
maintain high quality goals during development, so these are useful
for testing.

I'm looking forward to your feedback.

Thanks for all of your efforts! A download will be starting presently...

-cd

[Ben Schwehn]

First, thanks for the update.

Second, when trying to compile a .net project (e.g a brand new .net
console or library project) that has <windows.h> included i get many
linker errors like the one below:

MSVCMRTD.lib(ms tartup.obj) : error LNK2022: metadata operation failed
(80131195) : Custom attributes are not consistent: (0x0c000002).
[...]
LINK : fatal error LNK1255: link failed because of metadata errors
Any idea how to fix this?

Thanks

--
Ben
http://bschwehn.de

[Kalafiorczyk]

Hello Brandon!

"Brandon Bray [MSFT]" <br******@onlin e.microsoft.com > wrote:

I'm looking forward to your feedback.

How hard would be for you guys to make /clr:safe and /clr:oldSyntax
non-exclusive? To me it seems that only cl.exe needs to be changed.
Internally, /clr:safe gets translated to /clr:safe /clr:newSyntax.

This should be a really simple change and would allow to preserve
investment of people who wrote code using "__gc" extensions.

Thank you for your attention,

Sylvester

[Brandon Bray [MSFT]]

Ben Schwehn wrote:

Second, when trying to compile a .net project (e.g a brand new .net
console or library project) that has <windows.h> included i get many
linker errors like the one below:

MSVCMRTD.lib(ms tartup.obj) : error LNK2022: metadata operation failed
(80131195) : Custom attributes are not consistent: (0x0c000002).
[...]
LINK : fatal error LNK1255: link failed because of metadata errors
Any idea how to fix this?

It took a little bit to track this down, but we did it. This is caused
because we moved the NativeEnumAttri bute from Microsoft.Visua lC.dll to
another assembly. The managed CRT has a few enums (probably from windows.h)
that have the old location, while your code has the new location. (I
personally think the Attribute shouldn't even be there).

Anyways, this is fixed by building with a newer msvcmrt.lib or msvcmrtd.lib.
We will package that and provide it with the next refresh. We'll try to get
that done next week.

I'm sorry for the inconvenience.

--
Brandon Bray, Visual C++ Compiler http://blogs.msdn.com/branbray/
This posting is provided AS IS with no warranties, and confers no rights.

[Ben Schwehn]

> Anyways, this is fixed by building with a newer msvcmrt.lib or msvcmrtd.lib.

We will package that and provide it with the next refresh. We'll try to get
that done next week.

great, thanks!

[Kalafiorczyk]

Hello Brandon!

"Brandon Bray [MSFT]" <br******@onlin e.microsoft.com > wrote:

I'm looking forward to your feedback.

How hard would be for you guys to make /clr:safe and /clr:oldSyntax
non-exclusive? To me it seems that only cl.exe needs to be changed.
Internally, /clr:safe gets translated to /clr:safe /clr:newSyntax.

This should be a really simple change and would allow to preserve
investment of people who wrote code using "__gc" extensions.

Thank you for your attention,

Sylvester

[Brandon Bray [MSFT]]

Ben Schwehn wrote:

Second, when trying to compile a .net project (e.g a brand new .net
console or library project) that has <windows.h> included i get many
linker errors like the one below:

MSVCMRTD.lib(ms tartup.obj) : error LNK2022: metadata operation failed
(80131195) : Custom attributes are not consistent: (0x0c000002).
[...]
LINK : fatal error LNK1255: link failed because of metadata errors
Any idea how to fix this?

It took a little bit to track this down, but we did it. This is caused
because we moved the NativeEnumAttri bute from Microsoft.Visua lC.dll to
another assembly. The managed CRT has a few enums (probably from windows.h)
that have the old location, while your code has the new location. (I
personally think the Attribute shouldn't even be there).

Anyways, this is fixed by building with a newer msvcmrt.lib or msvcmrtd.lib.
We will package that and provide it with the next refresh. We'll try to get
that done next week.

I'm sorry for the inconvenience.

--
Brandon Bray, Visual C++ Compiler http://blogs.msdn.com/branbray/
This posting is provided AS IS with no warranties, and confers no rights.

[Brandon Bray [MSFT]]

Kalafiorczyk wrote:

How hard would be for you guys to make /clr:safe and /clr:oldSyntax
non-exclusive? To me it seems that only cl.exe needs to be changed.
Internally, /clr:safe gets translated to /clr:safe /clr:newSyntax.
The fact that /clr:safe and /clr:oldSyntax override each other was a design
decision. We are focusing all of our energy on making the new syntax
something we can support for the long term, and as such many of the features
that accompany it (like verifiable code) is tied to that design.
This should be a really simple change and would allow to preserve
investment of people who wrote code using "__gc" extensions.

When Visual C++ 2005 is on the market, we are highly recommending code gets
moved to the new syntax. We're doing that inside Microsoft which should give
us plenty of experience to share with everyone else. We are also writing
tools that can help the move. I've tried my hand at translating a few files,
and I found it quite easy to do. The translation is straight-forward.

I hope you understand.

--
Brandon Bray, Visual C++ Compiler http://blogs.msdn.com/branbray/
This posting is provided AS IS with no warranties, and confers no rights.