By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,244 Members | 1,772 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,244 IT Pros & Developers. It's quick & easy.

Visual C++ Tools Refresh ready today

P: n/a
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.
Nov 17 '05 #1
Share this Question
Share on Google+
18 Replies


P: n/a
> 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/
Nov 17 '05 #2

P: n/a
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
Nov 17 '05 #3

P: n/a
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(mstartup.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
Nov 17 '05 #4

P: n/a
Hello Brandon!

"Brandon Bray [MSFT]" <br******@online.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

Nov 17 '05 #5

P: n/a
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(mstartup.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 NativeEnumAttribute from Microsoft.VisualC.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.
Nov 17 '05 #6

P: n/a
> 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!
Nov 17 '05 #7

P: n/a
Hello Brandon!

"Brandon Bray [MSFT]" <br******@online.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

Nov 17 '05 #8

P: n/a
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(mstartup.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 NativeEnumAttribute from Microsoft.VisualC.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.
Nov 17 '05 #9

P: n/a
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.
Nov 17 '05 #10

P: n/a
> 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!
Nov 17 '05 #11

P: n/a
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.
Nov 17 '05 #12

P: n/a
Hello Brandon!

Thank you very much for your thoughtful reply.

"Brandon Bray [MSFT]" <br******@online.microsoft.com> wrote:
The fact that /clr:safe and /clr:oldSyntax override each other was a design
decision.
Well, syntax should be syntax only and mostly separate from the semantics.
It was and it is possible to write verifiable code using the old
syntax (modulo the "unverifiable header" problem).
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.
Sir, one thing that you are probably missing is that I'm a free man.
I travel only the two-way roads, even if I have to put more miles.
Your road and Stan Lipmann's tool is one-way only.

Please remember that there are more people like me, with the
similar mindset. You guys have gotten quite successful at splitting
the C++ standard at the committee level. But the programmer's
and designer's mindsets will be much harder to split, even with
all the MSFT's money.
I hope you understand.


Yes, I think I do. And I'm explicitly trying to change your (singular
and plural) decision. It is early enough to do it; and you guys have
enough smart people around to have a 360 degree look before you
commence your trip and burn the bridges.

I hope that you can understand that changing your mind now is in your
good long-term interest. I can imagine that advocating a
mindset like the one described above may be difficult on MSFT's
campus. You may succeed at making C++ a first class .NET language
in Redmond, but it won't happen everywhere else.

Thank you again for your time,

Sylvester

Nov 17 '05 #13

P: n/a
Hello Brandon!

Thank you very much for your thoughtful reply.

"Brandon Bray [MSFT]" <br******@online.microsoft.com> wrote:
The fact that /clr:safe and /clr:oldSyntax override each other was a design
decision.
Well, syntax should be syntax only and mostly separate from the semantics.
It was and it is possible to write verifiable code using the old
syntax (modulo the "unverifiable header" problem).
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.
Sir, one thing that you are probably missing is that I'm a free man.
I travel only the two-way roads, even if I have to put more miles.
Your road and Stan Lipmann's tool is one-way only.

Please remember that there are more people like me, with the
similar mindset. You guys have gotten quite successful at splitting
the C++ standard at the committee level. But the programmer's
and designer's mindsets will be much harder to split, even with
all the MSFT's money.
I hope you understand.


Yes, I think I do. And I'm explicitly trying to change your (singular
and plural) decision. It is early enough to do it; and you guys have
enough smart people around to have a 360 degree look before you
commence your trip and burn the bridges.

I hope that you can understand that changing your mind now is in your
good long-term interest. I can imagine that advocating a
mindset like the one described above may be difficult on MSFT's
campus. You may succeed at making C++ a first class .NET language
in Redmond, but it won't happen everywhere else.

Thank you again for your time,

Sylvester

Nov 17 '05 #14

P: n/a

Brandon Bray [MSFT] wrote:
*Ben Schwehn wrote:
Second, when trying to compile a .net project (e.g a brand ne

.net
console or library project) that has <windows.h> included i ge

many
linker errors like the one below:

MSVCMRTD.lib(mstartup.obj) : error LNK2022: metadata operatio

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 i
caused
because we moved the NativeEnumAttribute from Microsoft.VisualC.dl
to
another assembly. The managed CRT has a few enums (probably fro
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 o
msvcmrtd.lib.
We will package that and provide it with the next refresh. We'll tr
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 n
rights. *

I am wanting to use Windows Forms with MFC but was disappointed wit
Visual Studio 2005 Beta. My heart rejoiced when I found out that ther
was a tools refresh. So, I immediate tried to get my existing projec
to work with it. Since then I have had 2 problems, one in release an
the other in the debug build.

In the release build, I received numerous errors stating that th
CWinFormsEventsHelper class does not have a get_Control() method.
fixed this by changing 'afxwinforms.inl'. The changes are below wit
the original commented out and the revisions just below it.

_AFXWIN_INLINE System::Windows::Forms::Control^
CWinFormsControlSite::get_Control() const
{
//System::Windows::Forms::Control
pControl=m_gcEventHelper->get_Control();
//ENSURE((CWinFormsEventsHelper^)m_gcEventHelper!=nu llptr &
pControl!=nullptr);
//return pControl;
ENSURE((CWinFormsEventsHelper^)m_gcEventHelper!=nu llptr);
System::Windows::Forms::Control^ pControl=m_gcEventHelper->Control;
ENSURE(pControl!=nullptr);
return pControl;
}

When I made these corrections and re-compiled. My release buil
generated the same errors as found in my debug build. They are a
follows:

101 instances of:
MSVCMRT.lib(mstartup.obj) : error LNK2022: metadata operation faile
(80131195) : Custom attributes are not consistent: (0x0c000002).

Followed by one instance of:
LINK : fatal error LNK1255: link failed because of metadata errors

I am thankful that someone else have already found this error, that yo
have diagnosed it and have committed to fixing it in one week (as o
August 28). My questions are as follows:

1) Where will the fix be made available so that I won't b
re-downloading the original Tools Refresh?

2) Will it still be out this week? [Today is September 1]

3) Was it ok to make the change to the 'afxwinforms.inl' file so tha
my release build will generate the same error as the debug? Will tha
be in the Update or will I need to make that change again
-
jwaterlo
-----------------------------------------------------------------------
Posted via http://www.codecomments.co
-----------------------------------------------------------------------

Nov 17 '05 #15

P: n/a
jwaterloo wrote:
I am wanting to use Windows Forms with MFC but was disappointed with
Visual Studio 2005 Beta. My heart rejoiced when I found out that there
was a tools refresh. So, I immediate tried to get my existing project
to work with it. Since then I have had 2 problems, one in release and
the other in the debug build.
Before I address your questions, the next Beta will also have some library
code to assist with this integration. We're not planning to include this in
the refreshes as of now, but depending on our situation that may change.
1) Where will the fix be made available so that I won't be
re-downloading the original Tools Refresh?
A new tools refresh will be posted to the MSDN Visual C++ Devcenter just
like the last one -- just watch that page, or you could subscribe to Brian
Johnson's RSS feed. I'm sure someone (perhaps me) will mention it on the
newsgroups too.
2) Will it still be out this week? [Today is September 1]
Most of the Visual C++ team was away earlier this week, so we're catching up
again. We're nearly ready to package a new build and we have scheduled time
to test it on Monday. It will be available shortly thereafter.
3) Was it ok to make the change to the 'afxwinforms.inl' file so that
my release build will generate the same error as the debug? Will that
be in the Update or will I need to make that change again?


Since I don't spend much of my time in the MFC code base, I don't have a
clear answer for this. I do know this scenario is one were trying to
support. I'd suggest filing an issue in the MSDN Product Feedback center
(link below). If your code fix is appropriate, the issue you file will track
its progress. If it's not the right fix, the response from the libraries
team will say what to do instead.

I hope that helps!

--
Brandon Bray, Visual C++ Compiler http://blogs.msdn.com/branbray/
Bugs? Suggestions? Feedback? http://msdn.microsoft.com/productfeedback/
Nov 17 '05 #16

P: n/a
Hi Sylvester,
I'd like to understand the scenario you are actually seeking. As I
understand it, you would like to keep a source base that can compile with
the VC7.1 and VC8.0 compiler. I believe the only reason that might be needed
is to target the 1.x CLR.

Overall, the feature set between the old syntax and the new syntax is going
to diverge greatly over time. Already, the new syntax has far more
capability than the old syntax. If sticking with the old syntax is really
necessary (and I do want understand any reasons why this would be
necessary), sticking with an older compiler will offer just as much
capability as a newer compiler given the old syntax is not gaining any new
features.

Thanks for any information you can provide.

--
Brandon Bray, Visual C++ Compiler http://blogs.msdn.com/branbray/
Bugs? Suggestions? Feedback? http://msdn.microsoft.com/productfeedback/
Nov 17 '05 #17

P: n/a
(1)======

ASP .NET Web Service Projects do not compile any more:
c:\Development\NTiTy\web\zPbWebService\zPbWebServi ceClass.h(33) : error
C2660: 'System::ComponentModel::Container::Dispose' : function does not take
0 arguments

(2)======

Inclusion of <winsock2.h>, <stdio.h> and <iostream.h> into an ASP .NET Web
Service Project produces the following warnings:
c:\Program Files\Microsoft Visual Studio
8\VC\PlatformSDK\Include\WinSCard.h(58) : warning C4394: 'g_rgSCardT0Pci' :
per-appdomain symbol should not be marked with __declspec(dllimport)

c:\Program Files\Microsoft Visual Studio
8\VC\PlatformSDK\Include\WinSCard.h(59) : warning C4394: 'g_rgSCardT1Pci' :
per-appdomain symbol should not be marked with __declspec(dllimport)

c:\Program Files\Microsoft Visual Studio
8\VC\PlatformSDK\Include\WinSCard.h(60) : warning C4394: 'g_rgSCardRawPci' :
per-appdomain symbol should not be marked with __declspec(dllimport)

c:\Program Files\Microsoft Visual Studio 8\VC\include\stdlib.h(311) :
warning C4394: '_fileinfo' : per-appdomain symbol should not be marked with
__declspec(dllimport)

c:\Program Files\Microsoft Visual Studio 8\VC\include\wchar.h(178) : warning
C4394: '_wctype' : per-appdomain symbol should not be marked with
__declspec(dllimport)

c:\Program Files\Microsoft Visual Studio 8\VC\include\wchar.h(188) : warning
C4394: '_pctype' : per-appdomain symbol should not be marked with
__declspec(dllimport)

c:\Program Files\Microsoft Visual Studio 8\VC\include\wchar.h(189) : warning
C4394: '_pwctype' : per-appdomain symbol should not be marked with
__declspec(dllimport)
(3)======

The following problem does not relate directly to Tools Refresh, however I
would like to get an answer, since I tried Tools Refresh only to see if it
helps.

Once I include <iostream.h> (and nothing else - just a single #include line)
into a wizard-created ASP .NET Web Service project, the latter fails to run
off the web server ("module cannot be loaded"). The size of the DLL
increases from 30 to 300 kbytes.
Thanks

"Brandon Bray [MSFT]" <br******@online.microsoft.com> wrote in message
news:e8****************@TK2MSFTNGP09.phx.gbl...
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.



Nov 17 '05 #18

P: n/a
Brandon Bray [MSFT] wrote:
Most of the Visual C++ team was away earlier this week, so we're catching
up again. We're nearly ready to package a new build and we have scheduled
time to test it on Monday. It will be available shortly thereafter.


FYI, a new refresh is available. <http://msdn.microsoft.com/visualc>

--
Brandon Bray, Visual C++ Compiler http://blogs.msdn.com/branbray/
Bugs? Suggestions? Feedback? http://msdn.microsoft.com/productfeedback/
Nov 17 '05 #19

This discussion thread is closed

Replies have been disabled for this discussion.