migrations and lsmigrate tool

I am using the latest, free version of lightspeed for evaluation purposes at a new company I'm with. I'm trying to get lsmigrate.exe to migrate some db structures after the migration code project DLL is compiled, nuget'd up by teamcity, shipped off to octopus deployment server. I have a custom deployment step that runs lsmigrate (see below for actual command) but nothign is happening. sql profiler only shows queries hitting doing a select on dbversion table - so i can confirm lismigrate is connecting to DB and doing something.

C:\Program Files\PointRoll\WebSites\pointrolldevopswebapplication\bin>lsmigrate /p:SqlServer2008 /c:Server=.\;Database=ChupacabraDevOps;Trusted_Connection=True; /v:20150121183139

I also tried omitting the /v: - Also, there do not appear to be any forum messageson lsmigrate for over 2 years - is this still a supported tool? Also, the documentation for it is flimsy at best: lsmigrate providername connectionstring [to_version] (when in fact, I found out you need to specify /p, /c, and optionally /v)

I also added /x to show exceptions but there are't any. I read in some of the documentation for /help a line about specifying the folder of the SOURCE CODE as a parameter... is this truely the source code from teh migrated project, or the generated binary? I wouldn't want to carry source code throughout my CI/CD servers... Thoughts?

A little more info:

My solution has two projects, migration class project and webapplication project. My web app references the former, so that its compiled binaries get wrapped up via nuget by teamcity. I also reference the lsmigrate exe and its DLL dependencies as content so they get packaged up and shipped as well (i'd rather do this than plop them on my build server - atleast for now)... I'm going to attach a zip file of my vs.net 2013 solution if that helps. ( I excluded the exe it made the file too large to upload)

The parameters you are using seem fine, what is the value in the DBVersion table on the target server?

In terms of the "source code" query - I presume you mean the /s parameter? If so this is to specify a directory containing either an assembly containing the migrations or source code files containing the migrations - it can be either depending on how you wish to deploy them. Generally this would be a compiled assembly but using actual .cs/.vb files can be useful if you need any runtime modification prior to execution.

Jeremy

Thanks for the reply - my version is currently sitting at: 18000101000000

I modified my cmdline to point directly to my binary from my migrations project, and still no bueno:

C:\Program Files\PointRoll\WebSites\pointrolldevopswebapplication\bin>lsmigrate /p:SqlServer2008 /c:Server=.\;Database=ChupacabraDevOps;Trusted_Connection=True; /s:PointRoll.DevOps.DBMigrations.dll and I get an error "Failed: The diretory name is invalid. " so I drop the dll along with its dependancies in a subfolder and run the same command pointing explicitly or without hte parameter to the folder with /s:"C:...\bin\db-migrations\" and it runs, no exceptions, but DB isn't migrated.

I've even viewed the compiled assembly and confirmed the correct migration code is in place - see screenshot.

And fwiw - here is a screenshot of the sql profiler trace and lsmigrate command, when running with optional /v parameter.

I tried another idea - I created a new DB named test... and changed my connection string to point to this empty DB. Upon running (same cmdlines as above) - only table added is DBVersion, with one row with version of: 18000101000000

It sounds like the migrations are not being loaded then, it looks like you are loading via the compiled assembly, does it work if you point the tool at the source files for those migrations?

I will look at adding a logging flag to help in tracing whats going on here in the meantime.

Jeremy

Thanks Jeremy - pointing to the source code folder works. I would prefer not to do this since I'm trying to do continuous integration & delivery with build & deployment servers & nuget packaging artifacts and what not. This can be done but would prefer to just hit this compiled DLL.