Yes, Jenkins is running as a service. However, I have created a user account named Jenkins and I run the service on that account. I have verified that the Jenkins user account can run the unit tests successfully. I don't know what else is required to "give the service the ability to interact with the desktop". I have scoured the DCOM and service configurations, and I've experimented with all settings that seem possibly relevant, yet nothing works.
Actually, one thing works: In the DCOM configuration, there is a way to tell the system to always run Microsoft Excel applications as a specific user. I have told it to always run Excel as the Jenkins user. I don't know why this makes a difference because the Jenkins service is already running everything as the Jenkins user, yet this somehow suppresses the error. I am using this workaround for now, but I regard it as a kludge, and not as an acceptable long-term solution. With a little speculation, I think I can answer my own original question: Q: What does Jenkins do differently when it executes a Windows batch command that could explain the failure? A: Jenkins doesn't do anything differently, per se, but is running as a service, and when Windows decides what is allowed to happen on a computer, it doesn't just consider the user privileges; it also considers whether or not the commands were issued by a service. Microsoft Excel and other COM applications, in particular, seem to be off-limits to service-issued commands even when fully accessible to the user issuing the commands. Thank you, Slide, for your reply, and thanks to all others who read and considered my question. I am going to set this problem aside for now and come back to it later when I have spare time and possibly a fresh perspective. -TC On Sunday, July 19, 2020 at 7:10:39 AM UTC-7, slide wrote: > > Is your Jenkins running as a service? If it has to open Excel and is > running as a service, this can be an issue. You need to give the service > the ability to interact with the desktop. I believe this is in the service > settings, but you can Google and find information if it is not right there. > > On Sun, Jul 19, 2020, 06:45 TC <[email protected] <javascript:>> wrote: > >> I am new to Jenkins. I installed it today on a Windows 10 computer to >> automatically build (using the MSBuild plugin) and run unit tests (using >> NUnit Console as a batch command) on my .NET solution. Almost everything >> works perfectly, but I have been unable to solve one frustrating problem, >> despite working on it for hours: >> >> One unit test project fails, but only when run from Jenkins. I can run >> the same unit tests from anywhere, logged-in as anybody, and they pass. >> >> In an attempt to debug the problem, I created a new account called >> "Jenkins" and configured the Jenkins service to run under that account. I >> have configured my Jenkins project to execute "whoami" as a Windows batch >> command, and verified that Jenkins is running as the "Jenkins" user. I have >> verified that the "Jenkins" user can run the unit tests without error. I >> have logged-in as myself, used "runas" to impersonate the "Jenkins" user, >> and verified that the unit tests pass under those conditions also. Yet >> somehow when Jenkins runs the same tests as the same user, the tests fail. >> >> So my question is: What does Jenkins do differently when it executes a >> Windows batch command that could explain the failure? Because the unit >> tests run successfully outside of Jenkins, and only fail inside Jenkins, I >> think I can crack this problem if I just know more about the runtime >> environment Jenkins creates. >> >> About the error itself:The failing tests all automate Excel. The error >> reported by Excel is "Microsoft Excel cannot open or save any more >> documents because there is not enough available memory or disk space". >> Posts on the internet generally say this message indicates a DCOM security >> problem (and has nothing to do with memory or disk space). Giving the user >> sufficient privileges to launch, activate, and access Microsoft Excel >> applications should solve the problem. I've done that, giving the "Jenkins" >> user full permission on Excel applications, yet the error persists. >> >> All advice is appreciated. >> >> >> -TC >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-users/db1129ea-84dd-41ea-8349-8a887fa85853o%40googlegroups.com >> >> <https://groups.google.com/d/msgid/jenkinsci-users/db1129ea-84dd-41ea-8349-8a887fa85853o%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/f6a31dd1-ff14-41af-8a64-ccf0ecde70d1o%40googlegroups.com.
