yowl wrote:
I found that I didn't need a registry key. I'm using .Net 4.5.2 as the Platform (with adapter+MS SQL Server+LLBGen Framework), I had an issue with .netstandard, lack of TransactionScope I think.
From what I read this should be usable when using .net core 2.2 (which is released later this year) but haven't tested any code myself on 2.2 yet so can't confirm that this indeed works (knowing what's needed for transactionscope to actually work, I doubt it)
Agree the license file will always be an issue, I've just added the CI license to source control in the cligenerate.exe folder which may be a distribution violation, but I need to get it to the CI server in the cloud somehow. Maybe you have something you want to add around what is permissible here?
for the generator in a CI system, that's ok. The things we want to prevent are:
- people sharing a single license on a terminal server
- people using the generator/templates system in their own application, generating code at the backend.
I wished I could just give the cligenerator and it would just work, but point 2 above has bitten us a couple of times so we won't do that.
So hereby: if you need to distribute the license to the CI system through sourcecontrol, it's OK to do so, if the license is used by the code generator in the CI system only. (I think that's the way you use it). HTH.
I also had a minor issue with the preferences54.xml file. For what it's worth here is my command script which is working for me now in Azure DevOps in case its of interest to anyone else
mkdir %AppData%\"LLBLGen Pro"
cp ..\lib\llcoolj\cligenerator\Preferences54.xml %AppData%\"LLBLGen Pro"\
cd ..\lib\llcoolj\cligenerator
cligenerator %BUILD_REPOSITORY_LOCALPATH%\src\TheHub.Entities.llblgenproj .\TheHub.Entities\ 0
Thanks for sharing (hehe llcoolj)