Using Pre-Processor Directives

[Justin_Baur]

Hi,

DISCLAIMER: OnBase might already do this but I haven't seen any information about it.

I am trying to streamline my build process from Test to production environments.  Sometimes to have the same code run in test and production I need to take advantage or preprocessor directives (https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/preprocessor-directives/).  I was wondering or hoping that OnBase would define in the build a TEST and PROD compile time option so that I would not need to have a #define PROD or #define TEST in my scripts and remember to switch it in the new environment.  I also sometimes try to do my code in visual studio and copy it over. So it would be extra cool if OnBase also defined ONBASE no matter the environment so that my code would quickly know if it is in a ONBASE environment and that it doesn't need to make it own Hyland.Unity.Application object and can instead use the own that will come from the method arguments.  I don't think it would take to much work to make this happen in a future version it should be as easy as doing a -define in the arguments of the compiler (https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/preprocessor-directives/preprocess...). That is if they use the default C# compiler. 

Is this something that would interest anyone else.  I would also be interested in hearing about all of your guys build processes.  Do any of you develop something like a IWorkflowScript outside of OnBase and bring it in later?

[Valentine_Toka1]

My thought is if you can identify the database connection.  This could help you.  I have 2 odbc's  one for production and one for test.   You can create a standard ODBC. 

BUILD_Test & BUILD_PROD.  You identify the destination from the connection.  You might be able to adapt  ODBC_DEV &

ODBC_PREPROD for furture use. 

Valentine

🙂

[Justin_Baur]

My thought is if you can identify the database connection. This could help you. I have 2 odbc's one for production and one for test. You can create a standard ODBC. BUILD_Test & BUILD_PROD. You identify the destination from the connection. You might be able to adapt ODBC_DEV & ODBC_PREPROD for furture use. Valentine 🙂

That would let me execute different code based on the environment but using preprocessor directives would give me a different binary after the build process. This way I get the benefits of only writing different code for the different environments but also the speed of not having to evaluate which environment I am in on the fly.  Also doing it this way would required that my TEST code would have to compile in PROD as well. With it ignoring my code for TEST with a PROD directive it wouldn't require that my TEST code make any sense. 

[Christie_Rasiah]

You might able to identify the environment using  Application.SystemProperties.IsProduction

https://sdk.onbase.com/unitySDK/html/5d1296d0-fec9-1f39-ca0a-773a95128420.htm

[Justin_Baur]

You might able to identify the environment using Application.SystemProperties.IsProduction https://sdk.onbase.com/unitySDK/html/5d1296d0-fec9-1f39-ca0a-773a95128420.htm

I have no problem finding out runtime which environment I am in.  What I am asking for are build directives so that I can have separate binaries for production and test.  Doing it this way makes it so that my test code doesn't even need to compile when it is used in production and would make my code quicker since it wouldn't even be checking if it's in production during runtime.  This would give us more flexibility with our scripts.