Visual basic project does not build in NCrunch 1.43 - 1.46 for VS2012.
No error reported by NCrunch in tests window.
It does build using NCrunch 1.42, it does build using MSBuild, it does build using VS2012.
There are no code contracts, nor tests in this project, nor circular referencies.
Log:
[10:28:43.3053-BuildTask-96] ERROR (Internal): System.Exception: Unable to retrieve property values from expression in build output: $(OutDir)$(TargetName)$(TargetExt)
Server stack trace:
v #=q$80cUyJBFVqaVwAjY9zYGsWfkIJHM9zfgnQUzlMAR9Tww52tSn3vsQxh0Ac4EDG8x5NQv3EtFTy9pO$fyOq59Q==.#=qy2G8Aaqx_BZje5cyxhJThrSuXdGUynkLVJnUNgPcpVo=(IList`1 #=qV_GR7Le7ZqjMrIqKybrziw==)
v #=qKB9NNRPaer2PT0Ct9mhA5nKA_f6VSu8LCfLWdOY4ShGCiiieT$gWh_Myt3wmYqZDFEuy4Y7f1x1k7dvc4NP2oA==.#=qpKHFlNru3lxZLMz2wc5dzQi09bLpF5JsyCqw_zCAd_g=.#=qkwgh5rLzy5MAWfD7NH3V2u2H2xT3Zks8WrEIyvsMDI8eedG9mbl_ur6LtmI5aYES(#=qt8YrEIcaNbVZrKK9$Kfn60pMwc8BcC4QXSktTCbjPvMkNX5DfvqepoQ_gn0HOGEgsizoJFubVU8VvAudRlMFhw== #=qnrYD3O2hG1vLwDA4bEZedg==)
v nCrunch.Common.ListExtensions.Do[T](IEnumerable`1 list, Action`1 action)
v #=qKB9NNRPaer2PT0Ct9mhA5nKA_f6VSu8LCfLWdOY4ShGCiiieT$gWh_Myt3wmYqZDFEuy4Y7f1x1k7dvc4NP2oA==.#=qNLm87GIrjs0a50JvkE1tsZqFhoG0UY7NtjviFfy2L49ZQ5pKjGbgT7Ae8I_f9Xf9(IList`1 #=q5bOY9hxtSqdzC$f2kdpuyA==)
v #=qMCd1lwS9mdEyvkcb61MIjCm6x96H3scHqf3H_KZEe3vCEosHs9LiTfpT0ftCD_Ip.#=qf5cRFW_H4psykesPVWCnKn_iDz5UmtneAZKTLYCT606AuzcHSGYyVNzJ9k5BCW1h(IList`1 #=qumJ3kuEhiIMFLQSE1xPaBQ==)
v nCrunch.Compiler.RemoteBuildRunner.Build(ComponentBuildParameters parameters)
v System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Object[]& outArgs)
v System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at nCrunch.Compiler.IRemoteBuildRunner.Build(ComponentBuildParameters parameters)
at nCrunch.Core.BuildManagement.BuildProcessLauncher.#=qTJIsp0A1vVut6jPiMzTKRqJcH5UgllvLkxESadicZo4=.#=qXBZMpecoz$00Bb4KhTjJAgQQ$H2JVL092EqW3upc4JOgPog2qPS6OT4fXokyPY9W(IRemoteBuildRunner #=qtfwMHWywNOBF7wV0lukVSxLtGRZ5lhGia$2OsDkHuKM=)
at nCrunch.Core.BuildManagement.BuildProcessLauncher.#=qSWlLHA_bXaX1RqpzzixFJzGwkbYcS7sx0VK5Dk9eDzY9pYNfiIgSBv3ojeYT0NLE(Action`1 #=q2KSPLCERhh0fpgECe3cL2w==, ProcessorArchitecture #=qv6govqAV_yxWuZszGiCVg6vaUcf0HYYQv5JoEU17Gi8=)
at nCrunch.Core.BuildManagement.BuildProcessLauncher.BuildComponentInExternalProcess(ComponentBuildParameters parameters, ProcessorArchitecture processorArchitecture)
at nCrunch.Core.BuildManagement.BuildEnvironment.Build(SnapshotComponent snapshotComponentToBuild, IList`1 referencedComponents)
at nCrunch.Core.BuildTask.DoProcessTaskAndReturnSuccessFlag()
at nCrunch.Core.Processing.ProcessingTask.ProcessTaskAndReturnSuccessFlag()
at nCrunch.Core.Processing.ProcessingQueue.#=qGOiQmCwBPeHfhhx_4PVPEQ==(ProcessingTask #=q_h$C_TjNNwxbXZU32L$brg==)
NCrunch reports this when a build fails to complete without returning any errors. There are certain situations in MSBuild that can cause this. Sometimes MSBuild actually represents reference resolution errors as warnings, which can be quite misleading and tends to confuse NCrunch (hence the lack of error information).
If you haven't tried it already, it's worth putting NCrunch in compatibility mode for this solution to see if there is an obvious configuration setting that will resolve the problem.
You may also be able to get more detailed error information from the build by setting the logging verbosity to detailed, then inspecting the failed build task in the Processing Queue window and examining the trace output at the bottom of the window. If you can't find anything in this that indicates a problem, feel free to copy/paste the trace output here and I'll help you take a look.
There are some MSBuild warnings about referencing x86 platform assembly from MSIL compiled one.
Project, that does not build is MSIL.
But there are more MSIL projects in the solution with such references, that build fine.
Thanks for sending through the log file. Sadly, it doesn't seem to have put much light on the real source of this problem. Is there any chance you could also try submitting a bug report straight after the issue has appeared? The log in the report may give some more information.
Something else that could be worth trying is to build your project directly as it exists in the NCrunch workspace using MSBuild on the command line.
After the build has failed, right click on the failed build in the Tests Window then choose Advanced->Browse to workspace. Look for the project file inside the nested directories created by NCrunch. When you've found it, try executing MSBuild.exe against it using the command line. You can usually find MSBuild.exe inside your .NET framework directory (i.e. C:\Windows\Microsoft.NET\Framework\v4.0.30319). After the build has run, check to see if the output files (i.e. the DLL) have been correctly created. You may need to execute the build with the parameter '/v:d' to get more verbose output if it doesn't provide you with an error.
Executing the build on the command line in the NCrunch workspace is fairly close to what NCrunch does internally, so I hope this should give us the vital clue as to why this is failing.
The MSBuild on the workspace version of the project succeeds. Nothing to update - that means NCrunch has already created the target assembly.
So I deleted the assembly and obj folder. Again, success, no suspicious warning.
Thanks, this information helps narrow things right down. My suspicion is that this VB project is not specifying a critical piece of build metadata that is required by NCrunch in order to build it.
I'm wondering if you'd be able to try adding the following build property group to the end of the .vbproj file:
This should force a specification of the properties NCrunch needs in order to find the DLL file after it's built. If this doesn't do the trick, let me know and I'll see if I can arrange a diagnostic build for you to try and get more information about this project.
It didn't help (I changed the values to mach my settings).
Is it possible, that the source of the issue is some referenced project? Can adding the property group to all referenced projects possibly help?
This build has been modified to give extra build trace information when the issue appears. I'm hoping this will give us some clue as to what is happening. You'll need to set your Log Verbosity to 'Detailed', then reset the engine and examine the trace log in the Processing Queue for the failed build. If you're uncomfortable posting the output here, you're very welcome to send it through the contact form. In theory, the bug report submitter should also pick up the trace information if you find this a more convenient way to transfer it.
Bohumil and I had a brief offline online exchange where we identified that the reason for this failure was that NCrunch was missing a piece of critical data within the .proj file XML. The project in question was missing the DefaultTargets attribute on the root Project element as normally specified at the top of the file. For example:
<Project xmlns="(- BROKEN LINK -)" ToolsVersion="4.0">
.. Needs to be:
<Project xmlns="(- BROKEN LINK -)" DefaultTargets="Build" ToolsVersion="4.0">
Adding the 'DefaultTargets="Build"' to the project file immediately resolved the issue.
A fix will be included in the next NCrunch release to better handle this situation.
A big thanks goes to Bohumil for the detailed analysis of the issue.