Upgrade to VS2010 & building a package

Nov 7, 2010 at 6:33 PM


On my fork, I've upgraded the solution to VS2010 using the usual upgrade wizard. The main projects still target 3.5 but the test projects are targeting 4, a restriction in VS. Also made a minor fix in T4 template because of this breaking change.

I am wondering how you build a package for this? I know there are only a few files but there doesn't appear to be an scripts / msbuild / nant files.... I would like to automate that part, and make it at least single (er double) click and reduces friction for people to build from the source (including myself).

- Damian


Nov 7, 2010 at 7:19 PM

Hi Damian

One of the tenets in my own head that was behind StoryQ was limiting the number of dependencies that a developer needs to install / get / understand in order to start using BDD. That's why StoryQ is, at it's core, just a DLL file that you reference in your test project.

Speaking from a point of view of complete ignorance, what do the powershell scripts give you that ctrl+shift+b in visual studio doesn't? 

I'd like to make it super-easy for people to build from source, and if possible that means not require them to install anything extra. That's not a "no" to your psake scripts, i'd just like to explore the alternatives first

Thanks so much for your contributions - Rob

Nov 7, 2010 at 11:01 PM

>Speaking from a point of view of complete ignorance, what do the powershell scripts give you that ctrl+shift+b in visual studio doesn't?

The ability to build without having to open visual studio ;)

To build with psake, right click on invokebuild.ps1 in explorer -> run with powershell... and that's it.

Ayende has an interesting post on psake. It doesn't replace msbuild, doesn't require isn't anything extra to install and doesn't stop a user opening in VS and ctrl+shift+b. Only point of friction is to perhaps enable running of unsigned scripts, which most devs seem to do anyway.

So with a right-click + run,  I am intending the following steps, for my team anyway:

- (Possibly) update the assembly file version with CI build version
- Compile
- Run all unit tests / specs
- Create a NuGet pack
- Copy the build output to a build dir ('build') with just the artifacts a user may need.

I have my StoryQ fork being built on my company's CI (TeamCity) and the above helps a lot. In my own projects (none oss yet) I also run reports such as code coverage and style cop. But that is out of scope here :)

I personally love when an OSS project comes with a single .bat or similar to just does the build and puts it all together.

Have you considered making StoryQ builds available via http://teamcity.codebetter.com (login as guest)? It could be useful for people to easily get new builds from your repo without waiting for a release.

In any case, it's up to yourself, it won't affect my contributions. If you decide not to take it, do something else (or nothing at!), I'll move it off to my own separate branch (or something similar) for my own purposes.

And you are welcome :)



Nov 11, 2010 at 3:17 PM

BTW, if you want to have StoryQ running on a CI server, you can do it for free on the CodeBetter site more info here http://jameskovacs.com/2009/02/24/announcing-teamcitycodebettercom/


Nov 12, 2010 at 9:41 AM

Thanks UserNameDoes. I've applied for a spot on their servers

Nov 12, 2010 at 9:44 AM

Hi Damian, i've managed to fix that languagepack t4 generation from "generate.bat" by replacing it with "generate.ps1". Would you mind taking a look at my powershell script and seeing if it can be made more psake-like? 

It's in the following revision:


Cheers - Rob

Nov 13, 2010 at 10:57 AM

Sure, will do.

Nov 14, 2010 at 3:59 PM
Edited Nov 14, 2010 at 4:01 PM

After some investigation, there appears to be an interesting problem that I didn't forsee...

Generate.bat and Generate.ps1 rely on TextTemplating,exe version 1.2 which is installed with VS2008. I get an "is not recognized as the name of a cmdlet, function, script file, or operable program" error because I only have VS2010 installed. I suspect you have both...

The alternative is to use the TextTemplating engine installed with VS2010 (version 10.0) which is in path "C:\Program Files (x86)\Common Files\Microsoft Shared\TextTemplating\10.0\TextTransform.exe". This works but generates an interesting warning:

"TextTransform.exe : obj\StoryQ.flit.tt(7,4) : warning : The C# 2.0 and C# 3.5 compilers are no longer supported. Templates will always be compiled with the version 4 compiler instead of 'v3.5' as specified."

Now this suggests to me that the language packs will be .Net 4.0 assemblies, so requiring dependents to be targeting .Net 4, thus breaking back-compat with .net 3.5 :(

The options I see are:

  1. Target .Net 4, rely on VS2010 being installed and use TextTemplating v10.0.
  2. Include and distribute TextTemplating v1.2 inside the libs folder. This actually may be better from a CI point of view - would not require VS to compile (see related SO question: T4 without Visual Studio). This is my preference.
  3. Target .Net 4 and include TextTemplating v10.0 inside the libs folder.
  4. Revert everything ( noooooo! )

I also suspect, from a CI perspective, the dependencies on MSTest may have to be addressed (see Running mstest without Visual Studio).

You may have noticed inside invokebuild.ps1 the target framework is "4.0", the StoryQ.dll still build for v2.0 runtime.


Nov 14, 2010 at 4:42 PM

Hi Damian. Thanks for looking into this.

Generate.bat is deprecated now, I just left it there for reference while we work on the Ps1. I think we should move forward to version 10 of TextTemplating.exe. That warning is actually about the version of C# code that the template generator uses (the intermediary code), it's up to me to make sure that the output of the template is in fact compliant with the 3.5 compiler, and us to make sure the compiler targets the right version for the code that's generated there, so that's no problem. We can get rid of that warning quite easily.

I think it's safe to assume that anyone building StoryQ has VS2010. Do you know if there are any licensing issues with bundling TextTemplating.exe et all in your own lib folder?

StoryQ can depend on NUnit instead of MSTest by changing the build target (there's a bunch of #if statements in the unit test headers), so that's no problem.

Cheers - Rob

Nov 14, 2010 at 5:31 PM

No problem. :)

> I think it's safe to assume that anyone building StoryQ has VS2010

Ok, will go down that path. The current thought is to turn generate.ps1 into a psake task, will investigate.

> Do you know if there are any licensing issues with bundling TextTemplating.exe

Afaik, we can, but let me find a more definitive statement...

> I think it's safe to assume that anyone building StoryQ has VS2010

That may not be the case on the CodeBetter TeamCity server, I don't know. If it is installed, grand so.

Dec 11, 2010 at 8:33 PM

It would appear that you cannot include and distribute the TextTemplating executable with your app / source: http://stackoverflow.com/questions/1331767/distributing-microsoft-visualstudio-texttemplating-dll-with-custom-app

This is annoying, so do we..

  1. Use TT v 10 and drop .net 3.5 support.
  2. Require anyone building StoryQ to have VS2008 + VS2010 installed.

My opinion is to go with #2 for a while, but the decision is up to you.

Btw, added a build task to generate the language assemblies. You can check it out on my fork.