views:

916

answers:

4

Hi there,

I have been upgrading several different VS2008 projects into VS2010 and have found a problem with VB.Net projects when they are converted.

Once converted, the .vbproj files have changed from this in VS2008:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
   <DebugSymbols>true</DebugSymbols>
   <DebugType>full</DebugType>
   <DefineDebug>true</DefineDebug>
   <DefineTrace>true</DefineTrace>
   <OutputPath>bin\Debug\</OutputPath>
   <DocumentationFile>CustomerManager.xml</DocumentationFile>
   <WarningsAsErrors>41999,42016,42017,42018,42019,42020,42021,42022,42032,42036</WarningsAsErrors>
</PropertyGroup>

To this in VS2010:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
   <DebugSymbols>true</DebugSymbols>
   <DebugType>full</DebugType>
   <DefineDebug>true</DefineDebug>
   <DefineTrace>true</DefineTrace>
   <OutputPath>bin\Debug\</OutputPath>
   <DocumentationFile>CustomerManager.xml</DocumentationFile>
   <NoWarn>42353,42354,42355</NoWarn>
   <WarningsAsErrors>41999,42016,42017,42018,42019,42020,42021,42022,42032,42036</WarningsAsErrors>
</PropertyGroup>

The main difference, is that in the VS2010 version, the 42353,42354,42355 value has been added; Inside the IDE, this manifests itself as the following setting in the Project Properties | Compile section as:

"Function returning intrinsic value type without return value" = None

This isn't a problem when building code inside Visual Studio 2010, but when trying to build the code through our continuous integration scripts, it fails with the following errors:

[msbuild] vbc : Command line error BC2026: warning number '42353' for the option 'nowarn' is either not configurable or not valid

[msbuild] vbc : Command line error BC2026: warning number '42354' for the option 'nowarn' is either not configurable or not valid

[msbuild] vbc : Command line error BC2026: warning number '42355' for the option 'nowarn' is either not configurable or not valid

I couldn't find anything on Google for these messages, which is strange, as I am trying to find out why this is happening.

Any suggestions as to why Visual Studio 2010's conversion wizard is doing this?

+7  A: 

Have you changed your build script to use the 4.0 version of MSBuild? Looks to me like you haven't and MSBuild is complaining it knows nothing about warning 42353 etc. (which would make sense if they were introduced in 4.0)

Paolo
You're right - I haven't. It appears that my scripts are using the <msbuild> task as part of the NAntContrib project, which when I looked into it, appears that it's build using the 2.0 Framework.
Brett Rigby
This was exactly my issue as well. I'd love to find more documentation of the warnings that were introduced as part of the new system.
Russell Myers
+1  A: 

I repro this behavior on converted projects. Can't find any docs on what these warning numbers mean, the MSDN library hasn't been updated yet. Nevertheless, my compiler has no trouble with them. Your problem is almost certainly caused by your build server or scripts using an old version of vbc.exe. Be sure the one in c:\windows\microsoft.net\framework\v4.0.30319 compiles the code.

Hans Passant
No, I couldn't find anything either. Hopefully if other people stumble across this post for the same problem it may help them too.
Brett Rigby
+1  A: 

Just edit *.vbproj project file and delete all occurrences of 42353,42354,42355, this should fix the build problem.

Pera
You're right, it did fix the outcoming problems, but I would rather look towards the underlying problem as the other answers suggest of swapping out the vbc.exe version for that in the 4.0 Framework.
Brett Rigby
A: 

You're quite right to think that hacking the .vbproj files isn't really the solution. You need to edit the .config for the TFS build service to use the 4.0 version of MSBuild, as described at http://blogs.msdn.com/b/willbar/archive/2009/11/01/building-net-4-0-applications-using-team-build-2008.aspx . Note: service needs restarting for the change to take effect, and you'll need to use the correct directory for .NET 4.0 framework (blog specifies a beta version)

Kevin Flanagan