SeanKilleen

7/21/2014 9:19:51 PM #

Very cool announcement! Would love to use this tool in our CI process.

What will the licensing be for this specific tool? My team has two developers, each with a license. Will an additional license be needed for the "build server" user? I'm hoping not, because otherwise we'd currently have to stick with the free alternatives.

SeanKilleen

7/21/2014 9:21:39 PM #

Nevermind, sorry! Just read the licensing section of the documentation. Sorry for jumping the gun I see that it requires an NCrunch license but not an additional one specific to the build server. Thanks for making that licensing decision!

Remco

7/21/2014 9:35:48 PM #

You're welcome!  The intention was to try and make sure that everyone already using NCrunch would be able to freely pick it up and use it on their build servers.

JSkimming

7/23/2014 2:29:27 AM #

We'd like to use this with AppVeyor, but the need to run ncrunch.exe /license interactively makes it challenging, could the licence set-up be changed to 100% command line? I would understand if this option didn't support the 30-day evaluation license.

Remco

7/23/2014 6:48:02 AM #

Thanks! I'll look into it

JSkimming

7/29/2014 6:46:01 AM #

I've raised a suggestion with AppVeyor, and they seem keen:

We would love to integrate NCrunch with AppVeyor!

help.appveyor.com/.../294-standalone-ncrunch-support

Remco

7/29/2014 6:48:34 AM #

I'm happy to say that the full release of the console tool (v2.8) will include the ability to specify a license using the command-line (/license Name XXXX-XXXX-XXXX).  Was this the only blocking point for usage with AppVeyor?

JSkimming

7/29/2014 7:05:25 AM #

I don't know to be honest.

I recognised the interactive licence as a likely blocker as I believe AppVeyor only support silent custom installations using chocolatey, though they may add first class support (is in built support without a custom installation), as they have for xUnit, nUnit, and recently MSpec.

Either way, I think it's likely AppVeyor will need to add support for the XML format output by Standalone NCrunch, therefore, I imagine a schema for the XML would be useful.

I'll highlight your reply in the suggestion I raised and Feodor my post here himself, then you'll be getting it straight from the horse's mouth.

Remco

7/29/2014 3:18:28 PM #

I've just included this modification in a new pre-release build.  Check the blog post above for an updated download link (build .25).

JSkimming

7/29/2014 7:32:01 PM #

Hi, the text of the links have been updated to 2.8.0.25, but the href is still 2.8.0.22. By manually adjusting the URL I've been able to download 2.8.0.25, but you may want to further amend the blog post.

Remco

7/29/2014 9:08:07 PM #

Oops!  Sorry about that.  Fixed now.

Jni

8/4/2014 11:59:29 AM #

Hi,

1 - the fix for the privilege elevation worked like a charm. Thanks for that.

2 - This is more than 140 chars, so no twitter this time I'd like to know more about the possible exit codes. In particular, I'd like to distinguish between, say, a lack of license and a test fail. A few examples of different exit codes : Invalid license, cannot find solution, invalid arguments, Build failed, tests failed, output failed (i.e. access denied to /o). I think this would help a lot!

Thanks again!

Remco

8/4/2014 1:21:42 PM #

Sure

        OK = 0
        BuildFailure = 1
        TestFailure = 2
        GeneralFailure = 3
        LicenseFailure = 4

I'll also make a note to add these to the documentation.

damirault

8/17/2014 2:42:10 AM #

Very excited about the console tool version. Should help a lot on automatic verification. I'm running into a serious perf issue when running the console tool against my solution that I'm not seeing with the normal version of NCrunch.

When the console tool is running it is spending the vast majority of the time doing file IO creating and cleaning up workspaces (I estimate it at 15-20 minutes of a 25 minute run). The main culprit appears to be the copying 800MB of "Program Files (x86)\Microsoft SDKs\*" into 40ish of the 80ish workspaces generated and taking up 40 GBs of space at peak.

SDKs getting copied include:
-Cpp Azure Mobile SDK for Visual Studio 2013
-Cpp REST SDK for Visual Studio 2013
-Expression
-F#
-LightSwitch
-Microsoft Azure
-Portable
-RIA Services
-Silverlight
-TypeScript
-Windows
-Windows Azure
-Windows Phone
-WindowsPhoneApp

I'm not sure why all of these SDKs are getting copied, since the projects don't make use of most of them, being a C# Asp.Net application against Azure. Definitely no Phone, C++, F#, Expression, LightSwitch, Silverlight.

As far as I can tell none of these SDKs get copied over to the workspaces that NCrunch generates while running inside VS. Ideally these files wouldn't be copied at all, but barring that, it seems like symlinking these static files instead of copying them would also be helpful. Is there also a way to preserve workspaces via the console tool, instead of them being fully generated and fully cleaned up every run?

Remco

8/17/2014 10:06:25 AM #

Hi, thanks for sharing this!  Can you let me know the directory path that you are checking the source code out to?  Is this within Program Files (x86)?  If so, what happens if you move it somewhere else?

damirault

8/18/2014 3:11:48 AM #

The solution and code is in its own dedicated folder directly under C:\, not in Program Files or any system folders.

I do have the NCrunch WorkspaceBasePath set to C:\NCrunch to alleviate some issues with very long paths being generated during compile (however, I am using the same globalconfig between the console tool and VS).

Remco

8/18/2014 11:48:04 AM #

Thanks!  I've now managed to reproduce and fix this problem.  It looks as though everyone was affected by it, although your situation may have been more extreme due to the number of Program Files dependencies in your solution.

Would you be able to try the updated download link above to see if this resolves the problem for you?