Build 2280: Visual Studio/MSBuild Actions - Platform options missing

Continua CI Discussion
1

G'day,

I've been working through some Visual Studio and MS Build actions in Continua and I think there is some missing functionality. In final builder 7 you have an option for Visual Studio solution to specify the configuration and platform via text like "Debug|x86". However similar UI options are not in the Continua Action for Visual Studio. As my edition of Continua runs on my x64 server and workstation it seems to limit the platform (AnyCPU/AllPlatforms configuration for Visual studio projects.

If I use MSBuild, it looks like it defaults to the C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ directory for the build process. If I pass in the "platform = x86" MS Build property, it's ignored. See screenshot. If you look at the error message at the bottom, it spits out the message "Reference Assembly 'System.Data.dll' targets a different processor.

Attachment unavailable

2

Hi Jamie

I have not been able to reproduce the problem here, In VS2010, I created a simpe vb.net class library, added System.Data and System.Web references, created x86 and x84 debug configurations, built it using Continua, with the same settings as you have and it build fine (on an x64 machine).

I googled this error and it doesn’t seem to be that uncommon :

http://stackoverflow.com/questions/13614854/visual-studio-2012-adds-reference-to-wrong-dll

http://mikaelkoskinen.net/changing-project-s-references-based-on-the-build-configuration

3

With regards to the Visual Studio action, that doesn’t use MSBuild, it calls devenv.exe, and you can specify configurations in the format Name|Platform, eg. Release|x86

With MSBuild, the dev who wrote the action didn’t bother to allow that in the configuration field, we’ll take a look at that and see if we can add that functionalty in.

4

Do you have .net 4.5 installed? I suspect the reason I am not seeing the issue here is that I have VS2012/.NET4.5 install… which I did read somewhere fixes a lot of msbuild issues.

5

I did try the VS Action Configuration with “Debug|x86” but it didn’t seem to work as expected.
Yeah I do have VS 2012 + net4.5 installed. I’m however I’m trying to build with an older framework solution.

6

Try adding a PlatformTarget property (set to x86 or x64). Older msbuild project files do not have that… which may be the problem.

7

MS Build Results. 4 and 3.5 result in the same issue. Looks like the Executable (MSBuild.exe) is locked in. I couldn't find a way to configure MSBuild via another mechanism in Continua.

MS Build Action - Log

Working Directory: C:\Continua_WS\Ws\508\Source\Iims-Singapore-Kiln\src\Iims.BL.Nunit
Executable: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe
Arguments: /nologo /verbosity:diagnostic /target:"compile" /P:PlatformTarget="x86" /P:outputpath="C:\Continua_WS\Ws\508\Ouput\Tests\x86" /P:configuration="Debug" /noconsolelogger /logger

8

On the flip side, the Visual Studio Action with the configuration “Debug|x86” has progressed, now I’ve read the LOG more carefully and seen there was a problem with the library components in the repository that was stopping the build starting. Might be good to add that example in the online documentation. http://wiki.finalbuilder.com/display/continua/Visual+Studio+.NET+Action

9

You still need Platform even when you specify PlatformTarget, as that is what is matched in the project file’s configuration sections
[code]<PropertyGroup Condition="’$(Configuration)|$(Platform)’ == ‘Release|x64’"> [/code]

The 64bit version of MSBuild is perfectly capable of building x86 apps, that is not the problem. I am looking at whether we can force the use of the 32bit version somehow. The current property collector code is somewhat naive, the trick now is to see if we can change it without breaking existing projects.

10

Hi Jamie

Next update will have a new option on the MSBuild action that will allow you to set the bitness of the MSBuild.exe. The default setting will behave as it does now, ie based on the Agent operating system bitness. Note that if you change the MSBuild Platform, you are also changing the Agent Requirements, so if you set it to 32 Bit then you are setting a requirement that the agent has the 32bit version of the framework installed

 Attachment unavailable

11

Cheers for the change to the UI to help out. Build 2324 includes this new UI option. I've got a problem with some instability between successive runs of a project now this has been introduced. I'm having troubles tracking this down through the through the 20 odd builds I've done over the last 2 days.  There are some references to SDK installations in the log files, so I'm wondering if there is some requirement to have various SDK's loaded on the Continua Build Agents?

To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.

Use Case

I've got a set of "frameworks" which I have to compile against Net 35 and Net 40

I create directory structure in $Workspace$\Output\ to follow the Nuget package structures.

The VS 2012 solution is currently at NET40.

I use the Continua MSBuild Action to create the compiled editions of the dlls (NET35\x86; NET35\x64; NET40\x86; NET40\x64)

The Continua Log results show "Success" but there are disturbing messages within those logs. (Probably my fault + .net limitations).

Executing the MS Build actions seems to be inconsistent between continua builds, when no changes are made to the configuration of the Continua CI project.

Examples

Working Directory: C:\Continua_WS\Ws\560\Source\JD-Data-Kiln\src\JD.Data.ForUnitTestProjects
Executable: C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe
Arguments: /nologo /verbosity:normal /target:"Build" /P:TargetPlatform="x86" /P:outputpath="C:\Continua_WS\Ws\560\Output\JD.Data.ForUnitTestProjects.2.1.0.74\net35\x86" /P:configuration="Release" /noconsolelogger /logger:ParallelLogger,"C:\Program Files\VSoft Technologies\ContinuaCI Agent\Continua.Modules.Builds.MSBuild.v35.dll" C:\Continua_WS\Ws\560\Source\JD-Data-Kiln\src\JD.Data.ForUnitTestProjects\JD.Data.ForUnitTestProjects.vbproj

"C:\Continua_WS\Ws\560\Source\JD-Data-Kiln\src\JD.Data.ForUnitTestProjects\JD.Data.ForUnitTestProjects.vbproj" (Build target) (1) ->
(CoreCompile target) ->
vbc : warning BC40057: Namespace or type specified in the project-level Imports 'System.Threading.Tasks' doesn't contain any public member or cannot be found. Make sure the namespace or the type is defined and contains at least one public member. Make sure the imported element name doesn't use any aliases.
1 Warning(s)
0 Error(s)
 

Working Directory: C:\Continua_WS\Ws\560\Source\JD-Data-Kiln\src\JD.Data.ForUnitTestProjects
Executable: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe
Arguments: /nologo /verbosity:normal /target:"Build" /P:TargetPlatform="x64" /P:outputpath="C:\Continua_WS\Ws\560\Output\JD.Data.ForUnitTestProjects.2.1.0.74\net40\x64" /P:configuration="Release" /noconsolelogger /logger:ParallelLogger,"C:\Program Files\VSoft Technologies\ContinuaCI Agent\Continua.Modules.Builds.MSBuild.v40.dll" C:\Continua_WS\Ws\560\Source\JD-Data-Kiln\src\JD.Data.ForUnitTestProjects\JD.Data.ForUnitTestProjects.vbproj

 "C:\Continua_WS\Ws\560\Source\JD-Data-Kiln\src\JD.Data.ForUnitTestProjects\JD.Data.ForUnitTestProjects.vbproj" (Build target) (1) ->
(GetReferenceAssemblyPaths target) ->
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets(983,5): warning MSB3644: The reference assemblies for framework ".NETFramework,Version=v3.5,Profile=Client" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.
"C:\Continua_WS\Ws\560\Source\JD-Data-Kiln\src\JD.Data.ForUnitTestProjects\JD.Data.ForUnitTestProjects.vbproj" (Build target) (1) ->
(ResolveAssemblyReferences target) ->
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets(1605,5): warning MSB3243: No way to resolve conflict between "System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" and "System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089". Choosing "System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" arbitrarily.
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets(1605,5): warning MSB3247: Found conflicts between different versions of the same dependent assembly.
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets(1605,5): warning MSB3270: There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "System.Data", "AMD64". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.
4 Warning(s)
0 Error(s)

Conclusion

I could be a complete arse as say "I suspect there is something buggy in the parallellogger API that's involved". (Because I can blame another programmer for being late on my project hehehehe) However I'll be honest as say that I'm learning MSBuild command line options at the moment, so I just wonder if I'm not setting up the appropriate options to highlight disturbing warnings like MSB3243, so I can do further research on the issue raised from a CI build.

12

Hi Jamie

The loggers are selected based on the .net framework version, because there were subtle differences in the logger api’s between framework versions. The loggers are also compiled against their respective framework versions. These are essentially the same loggers used by FinalBuilder, they were ‘reverse engineered’ from the default msbuild loggers because there is zero documentation on how to write an msbuild logger that handles msbuild running in multithreaded mode. The only thing they do is take the msbuild output and reformat it so that Continua can parse it easily.

Have you tried building these projects using msbuild from the command line (ie take Continua out of the loop), do you still see these warnings? BTW, I found this tool a while ago, tells you about all the assembly references in your app. Might help in this case.