Add new command line switch -X to allow TMSL script generation

[msdotnetclr]

Add new command line switch -X|-XMLA xlma_script_file to allow TMSL script generation
When -X is used, only TMSL script is generated. Deployment will not be executed

E.g. TabularEditor.exe .\Model.bim -D server database -L ($username) ($password) -O -X database_release.xmla

[msdotnetclr]

This is for #289 Feature: Generate TMSL script from command line

[msdotnetclr]

Please note that in the most recent commits, the TabularEditor project output type is changed from Windows Application to Console Application. This should stop Command Prompt from returning immediately after starting the application, thus eliminating the need to use the "start /w" trick.

[otykier]

I actually tried changing the project type to Console Application at one point, but I decided against this, because we get a command window open in the background whenever you open the UI of Tabular Editor:

I think I'd prefer to change it back to Windows Application to avoid this, as the "start /w" trick is a small price to pay, to avoid the command window when all you need is the UI, while also having the CLI option within a single .exe.

Thoughts?

[dmarkle]

I think it's getting to be about time to think of refactoring a bit to make two apps -- a command-line EXE and a WinForms EXE.

You could potentially use the WinForms.exe as just a library for the command-line app as an interim step to a larger, longer effort of decoupling the logic from the forms itself. One of my concerns about going down the road of having just the Windows app is that it might stop working (does it now) if it's run on someone's Windows Server Core build server.

[msdotnetclr]

@dmarkle I was going to do what you suggested yesterday, but after analyzing the code, I found it requires fairly large amount of refactoring to make a clean cut, it won't "fit into" this particular PR. It would be a separate major PR.

[otykier]

@dmarkle That's a good point. As of today, the code is split into two projects:

TOMWrapper.dll, which does most of the stuff directly related to the Tabular Object Model, including deployment, save to file, etc.

TabularEditor.exe, which holds all the UI, including the code for the Best Practice Analyzer and scripting system (and the current CLI).

To refactor the CLI into its own application, we would need to refactor the BPA and scripting system out into its own DLL, removing the dependency to UI code. As @msdotnetclr remarked, this is a rather large change - especially considering that the scripting system is tightly integrated into the UI because of the ability to save scripts as custom actions that can be invoked through the UI. I knew a day would come, where my lazy coding would start to bite me in the butt...

I would suggest waiting until 3.0 before anyone starts working on this, as I have some major changes in the UI code coming up - I'll keep this discussion in mind.