Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

Tried creating a no-contract build configuration for ncrunch, ncrunch can't build anymore
Strilanc
#1 Posted : Wednesday, April 4, 2012 4:43:04 AM(UTC)
Rank: Member

Groups: Registered
Joined: 4/3/2012(UTC)
Posts: 17

Thanks: 1 times
I'm trying to create a build configuration, without code analysis or contracts, for ncrunch to use. But I seem to have dug myself into a hole, because I can't get ncrunch to build the solution at all anymore. I have two build configurations: Dev and ncrunch.

If I set the build configuration setting to be empty, meaning use the default, I get this error:

Quote:
Errors occurred while trying to load the project file:
The OutputPath property is not set for project 'nCrunchTemp_43d6cc7c-91da-4b9b-8022-86adeb75b4ad'. Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='Debug' Platform='AnyCPU'. You may be seeing this message because you are trying to build a project without a solution file, and have specified a non-default Configuration or Platform that doesn't exist for this project.

NCrunch: This error is commonly caused by projects that are relying on the selected build configuration provided by Visual Studio in order to set the $(Platform) and $(Configuration) MSBuild properties during a build. Unless configured otherwise, NCrunch will normally use the default $(Configuration) and $(Platform) properties that are specified in a .proj file - thus in order for your project to build with NCrunch it must be possible to build the project using command line MSBuild without needing to manually inject build properties. You will most likely need to edit your .proj file to align its default $(Configuration) and $(Platform) properties with the property groups provided in the file.


But if I use an explicit 'ncrunch' or 'dev' I get a null ref exception:

Quote:
(0): System.NullReferenceException: Object reference not set to an instance of an object.
at Mono.Cecil.SignatureReader.GetGenericParameter(GenericParameterType type, UInt32 var)
at Mono.Cecil.SignatureReader.ReadTypeSignature(ElementType etype)
at Mono.Cecil.SignatureReader.ReadGenericInstanceSignature(IGenericParameterProvider provider, IGenericInstance instance)
at Mono.Cecil.SignatureReader.ReadTypeSignature(ElementType etype)
at Mono.Cecil.MetadataReader.ReadFieldType(UInt32 signature)
at Mono.Cecil.MetadataReader.ReadField(UInt32 field_rid)
at Mono.Cecil.MetadataReader.ReadFields(TypeDefinition type)
at Mono.Cecil.TypeDefinition.<get_Fields>b__c(TypeDefinition type, MetadataReader reader)
at Mono.Cecil.ModuleDefinition.Read[TItem,TRet](TItem item, Func`3 read)
at Mono.Cecil.TypeDefinition.get_Fields()
at Mono.Cecil.MetadataReader.LookupField(UInt32 rid)
at Mono.Cecil.MetadataReader.GetFieldDefinition(UInt32 rid)
at Mono.Cecil.MetadataReader.LookupToken(MetadataToken token)
at Mono.Cecil.Cil.CodeReader.ReadOperand(Instruction instruction)
at Mono.Cecil.Cil.CodeReader.ReadCode()
at Mono.Cecil.Cil.CodeReader.ReadFatMethod()
at Mono.Cecil.Cil.CodeReader.ReadMethodBody()
at Mono.Cecil.Cil.CodeReader.ReadMethodBody(MethodDefinition method)
at Mono.Cecil.MethodDefinition.<get_Body>b__2(MethodDefinition method, MetadataReader reader)
at Mono.Cecil.ModuleDefinition.Read[TItem,TRet](TItem item, Func`3 read)
at Mono.Cecil.MethodDefinition.get_Body()
at #=qUxeqa6hlCRcyPCLUjLUb7HGoX4GMD1_YFK_fMiL90yS3s3kngB1Rug_cHUsZUv6Nz2b4NRgBTuezuwBO8NrQTg==.#=qJ1tNQvB19sPtvTiEgDo22dJshRfli34cydHFqYdYRjE=(Collection`1 #=qaqfqZGbOg0nwSDABAINyIg==)
at #=qUxeqa6hlCRcyPCLUjLUb7HGoX4GMD1_YFK_fMiL90yS3s3kngB1Rug_cHUsZUv6Nz2b4NRgBTuezuwBO8NrQTg==.#=qDqDlHqlxQdYhDXvsTU2ekijUk$8LdoTtldb$s5nfuaw=(IEnumerable`1 #=qSI7tSD5t3ZC7Sri5PQhnuA==)
at #=qUxeqa6hlCRcyPCLUjLUb7HGoX4GMD1_YFK_fMiL90yS3s3kngB1Rug_cHUsZUv6Nz2b4NRgBTuezuwBO8NrQTg==.#=qVXfmQMLUDaf7zrmwv79Zs7hextb83Nro8vigB5gqLgo=()
at nCrunch.Compiler.StaticManipulation.BuiltAssembly.Instrument(IMasterExecutionMap masterExecutionMap, IDictionary`2 codeFileIDsByFilePath, Boolean proxyProcessIsActive, Int32 componentId)
at nCrunch.Compiler.RemoteBuildRunner.#=qdNy3eJz0F0f31G1txMSXAEVeC9Nhq_sDLM7MDpb6eP4=(ComponentBuildParameters #=qFM_k3V64cVZZd6sixdAjJQ==, String #=q5kD4ablNlc2cGuLZ8hO5ofKufkiyaVkhJYyyaY6AOjk=, BuildOutput #=q5ZP__l8J9fM4dLoL5$V4RA==, String #=q24Q3Qm4opmQYnf8oCoGTHsDpE$DxmRGdIjH_hjrrCNU=)
at nCrunch.Compiler.RemoteBuildRunner.Build(ComponentBuildParameters parameters)


I'm not really sure how to fix this problem without completely recreating the solution or something.
Remco
#2 Posted : Wednesday, April 4, 2012 6:17:22 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,143

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
It looks to me like there is probably more than one thing that's gone wrong here. I hope you don't mind me asking a few questions to better identify what has happened:

- Do your msbuild .proj files build successfully via the command line? (i.e. run MSBuild against the project files individually without specifying any parameters or special configuration)
- Has NCrunch ever been able to build this solution previously? If so, try deleting all NCrunch related files from your project/solution directories while your IDE is closed
- What are the $(Configuration) options that you have available in your .proj files? If you could show me a code extract of the top section of one of your failing projects, that would be ideal
- Is this an open source project you're working on? I ask in the hope that I might be able to grab a copy of the source to help troubleshoot


Thanks!

Remco
Strilanc
#3 Posted : Wednesday, April 4, 2012 9:31:10 AM(UTC)
Rank: Member

Groups: Registered
Joined: 4/3/2012(UTC)
Posts: 17

Thanks: 1 times
I think I found the problem. I'm using the vs11 preview, and it appears that it's not storing changes to the project files in the project files themselves. Seems like they're going into a binary solution file ending with .v11.suo.

My guess is that ncrunch is reading the project file but not taking into account the changes hidden away in the binary solution file.

Hopefully there's a way to force the changes to flush to the project file... I don't really expect ncrunch to implement support for what is probably a temporary and highly volatile file format. Maybe a warning if it notices the file is present?

You should be able to test this problem by creating a visual basic project in VS2010 then modifying its configurations in VS2011.
Remco
#4 Posted : Wednesday, April 4, 2012 10:29:58 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,143

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
Wow, that sounds quite crazy, but it does make sense.

Is there a reason you're still using the VS11 preview? The VS11 Beta may be more stable with NCrunch.
Strilanc
#5 Posted : Wednesday, April 4, 2012 10:34:41 AM(UTC)
Rank: Member

Groups: Registered
Joined: 4/3/2012(UTC)
Posts: 17

Thanks: 1 times
I thought the beta was the preview. I have the beta installed. My mistake.

It's strange. Hovering over the task bar icon shows 'developer preview' but it is definitely the beta based on the splash screen and when I installed it.
Remco
#6 Posted : Wednesday, April 4, 2012 9:22:25 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,143

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
Ahh ok - sorry, the preview and beta are both very different things to me (and required different levels of pain in order to support!). I find it a bit disturbing that VS11 follows the behaviour you've described above, and will make a note to look into it deeper. The key issue is that NCrunch needs to be able to build projects in isolation (outside their parent solution), so storing large amounts of configuration in the solution itself would create problems.

My suggestion would be to try to introduce your alternative build configuration in the .proj files manually. This shouldn't be a difficult process (mostly copy/paste), and I would expect that the VS11 IDE would still pick up the changes as it needs to be backwards compatible with VS2010 projects. I'm keen to hear if this solves the issue for you.


Cheers,

Remco
Strilanc
#7 Posted : Thursday, April 5, 2012 2:31:37 AM(UTC)
Rank: Member

Groups: Registered
Joined: 4/3/2012(UTC)
Posts: 17

Thanks: 1 times
I posted it to Microsoft connect as a bug: https://connect.microsof...t-saved-to-project-files

-- hold on, something's weird --
...
Ok, now I'm really confused.

So, it looks like changes to configurations ARE making it to the project file, except not the SELECTED configuration. So despite having renamed 'Debug' to 'Dev' my project file still said

<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>

and also specified x86 when I've changed it to AnyCpu/MSIL everywhere I can find. Manually changing that line to say Dev instead of Debug fixed the issue.

My new guess is that ncrunch is trying to read the output path for the non-existing default 'debug' configuration when loading the project, even though it will ultimately only use the 'ncrunch' configuration.

Given this, I'd like to request that you not attempt to read the default configuration unless it will actually be used. Ideally reading it would cause no issue but... here we are.
Strilanc
#8 Posted : Thursday, April 5, 2012 3:14:52 AM(UTC)
Rank: Member

Groups: Registered
Joined: 4/3/2012(UTC)
Posts: 17

Thanks: 1 times
Now that the first issue is fixed I'm running into the second issue: null ref exception when building.

I don't see how to attack a file here, so I sent an email to you via the forum. Reply to it and I'll attach the project in question.
Remco
#9 Posted : Saturday, April 7, 2012 10:49:14 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,143

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
For anyone interested, Strilanc did some offline troubleshooting around this problem and determined it to be a defect in NCrunch that can be caused by certain IL configurations around generic types that can be emitted from the VB.NET compiler. A fix for this issue is currently underway.
Remco
#10 Posted : Sunday, May 20, 2012 11:39:17 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,143

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
For anyone interested, a fix for this issue has been released recently with v1.39b of NCrunch.
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.086 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download