So, for anyone dropping into this conversation.  I made some additional changes.   Honestly, I just couldn't get SAS EG and my application to work nicely together.  I just don't think that SAS EG has a strong enough integration model and I was wasting countless hours trying to make it work.  @AlanC was very helpful and seems to have achieved this, if you are really needing to go that route, I think you can reach out to him.   The way I ended up getting this to work pretty flawlessly, is to execute the process in PowerShell via my .NET code.  This decoupled the need for me to import any SAS modules or libraries into my code.  But I have a pretty simple need in that I just need to execute an existing .egp program at some location.   Thanks to everyone who assisted, perhaps I will revisit this in the future when I have more patience or when SAS exposes some better functionality. ... View more

Not "stand alone" in the sense that you still need SAS to be able to execute the programs within it. ... View more

Correct me if I'm wrong, but SAS EG is simply a system that allows a pipeline of SAS programs to run as a single unit.  It's not a stand-alone program.  It would make so much sense if SAS would open-source the code for this.  They would not be giving any insight into the actual internal workings of SAS or anything they need to be concerned about, but open-sourcing this project would allow people like me and you to contribute to it.  For instance, we could then expose better integration points that are much more universal in their usage and make them much more usable.   @AlanC , I tried to fund your username on GitHub and was not successful in finding any code examples.  Do you perhaps have a link? ... View more

Thanks @AlanC, I already have my API setup.  It's the execution of SAS that is the problem which is the reason I'm here.  The rest of the code was easy, but this integration is proving much more difficult than it should be. I was using this paper written by Kevin Kramer, https://support.sas.com/resources/papers/proceedings/proceedings/forum2007/016-2007.pdf.  But it just doesn't work.  The problem once again as I stated in the opening is that you cannot simply reference SASEGScripting.dll because it has a Windows.Forms dependency and uses MessageBox's making non-interactive operation impossible.  On top of that, assuming you can avoid all errors, you cannot get away with simply referencing that one DLL.  The program has dependencies such as SASIOMCommonInterop.dll, SASOManInterop.dll, LibGitToSharp, and the list goes on.  Just to get the program to run, I had to dump all the DLLs from SAS into my output folder. I will look into executing SAS EG from the command line, but I am just concerned that I will lose control of it (assuming it is some fire-and-forget).   @SASKiwi , thanks for the response.  I have actually spoken about this with my manager and trying to integrate multiple technologies in a pipeline is really overly complicated and he agrees.  We are just stuck in a place where we have the ETL tool and we have the SAS projects.  There are hundreds or thousands of them and we can't rewrite them, not without a massive cost and risk to the business.  We are not scheduling these processes, they are run on demand.   Honestly, I just expected more from such a large company as SAS and I'm very disappointed.  There should be a SAS-supported NuGet package that can be referenced where all the dependencies are taken care of with documentation on the various usages.   UPDATE:  I have managed (unfortunately using my hacked SASEGScripting.dll) to get the SAS EG to run to completion.  My next problem is that it's just not doing what it should.  It is now unable to move files from the dropped location into the SAS for execution.  The same EG executed manually on the server works just fine.  So I think I have some permissions that need to be taken care of.  Frustratingly, SAS reports successful execution even though the logs show otherwise.   I'm not out of the woods yet though, and this application really stinks of maintainability issues with a ton of debt.   I think, as a community, we need to start a community .NET integration GitHub page where we can publish a much-needed NuGet package.  Else, I need to quit my job and apply at SAS so I can sort this out for them. ... View more

@AlanC, thank you for your reply. To set the scene, I am not a SAS developer.   In our organization, we have a well-established ETL tool.  However, this tool is quite limited in its capabilities when it comes to "external tools".  One thing it can do is call an API endpoint.  On the other hand, we also have a well-established set of SAS processes that do some complex calculations.  These processes are saved as .egp files.   So, as a .NET developer, I have been asked to write an API endpoint, that when called by the ETL tool, will execute one of these .egp files.  What the .egp actually does is a bit of a black box to me.  What I know is that it ingests a bunch of files as a predefined location, then spits out the results in a separate location.  Once the process has run, the ETL tool picks up the resulting files and continues with whatever it needs to do.   Thanks for the info about these egp's just being zip files.  I have extracted one and found that it contains 185 code.sas, 16 xml files and log files.  I suspect this will be very different from one egp to the next.   What would you suggest is the best way forward?  Do I continue trying to work with these .egp files, or should I, as suggested by @Kurt_Bremser , convert them to .sas files and run them that way?  I assume there is a better .NET integration for that? ... View more