9

I have project that I build with the following command in zsh on a Windows 10 machine:

devenv $sln -project $project -rebuild "Release|x64"

If I run it locally in a terminal, it always works. I am however running it via the task scheduler and sometimes via (cygwin) ssh. It still works, but only if I'm actually logged into the machine locally or with a remote desktop session.

If the command is run when the user is signed out, I see the following message:

Microsoft Visual Studio has detected a configuration issue. To correct this, please restart as Administrator. For more information please visit: http://go.microsoft.com/fwlink/?LinkId=320596

Example using ssh.

  1. I log into physical machine
  2. I ssh into said machine
  3. Run command. Works fine.
  4. Sign out on physical machine
  5. Run command in the same ssh session. Fails.

When I say "physical machine" I mean the host machine where the command is run.

I have an up to date Windows 10 Professional machine and up to date Visual Studio 2013.

It also fails if the command is run via windows task scheduler (set to work when not logged in with highest privileges), while the user is signed out.

Setting devenv to always open as Administrator (using all the methods I've seen on S.O.) doesn't help. Disabling UAC doesn't help.

I would opt to just leave the machine logged in all the time, however the problem also occurs is after a Remote Desktop session:- If I remote desktop into that machine, the command continues to work while I have the remote session open (even via ssh and task scheduler), but as soon as I disconnect the rdp session it stops working.

Edit: The correct user profile is loaded at the point of execution and the devenv activity log reveals no errors or warnings. The log merely shows that devenv exits after Client rights determined.

Edit: I've tested @Callan's msbuild solution and it seems to work for all my projects using the following for solution builds:

msbuild $sln /t:Rebuild /p:Configuration=Release;Platform=x64

And the following for single project builds (Found here):

msbuild $sln /t:"$project:Rebuild" /p:Configuration=Release;Platform=x64 /p:BuildProjectReferences=false

This isn't strictly a solution to the problem, because as @SimonMourier pointed out, they're not equivalent. It's a workaround that fortunately works for me and while it may not work for all cases, it's starting to look like there isn't a better solution.

It's certainly better than my current workaround to make the machine auto login and lock, and then tell my machine to reboot at the end of an RDP session, ensuring I always have an interactive session.

Community
  • 1
  • 1
Jools
  • 839
  • 8
  • 22
  • 1
    Visual Studio needs a correct user profile to be loaded to run.Maybe related: https://support.microsoft.com/en-us/kb/2968540. Also, have you checked the activity log: https://blogs.msdn.microsoft.com/visualstudio/2010/02/24/troubleshooting-extensions-with-the-activity-log/ – Simon Mourier Jan 18 '17 at 07:29
  • As far as I can tell the correct user profile is loaded. Both `$USERNAME` and `$USERPROFILE` are set as expected. I've checked the log and the first 42 entries are identical for a failing and working build. The 43rd entry in a working build is `Entering function CVsPackageInfo::HrInstantiatePackage`, whereas in the failing build the program seems to just begin to cleanly exit `AppId stopped registry detouring`. The 42nd entry in both is `Client rights determined: ...` – Jools Jan 18 '17 at 13:09
  • Yes, I'm fairly certain that the correct user profile is loaded, as both logs report reading the `client rights token` from the same user directory. – Jools Jan 18 '17 at 13:21
  • 1
    What about credentials? VS now needs to connect to Microsoft and check the licence. – Simon Mourier Jan 18 '17 at 18:07
  • How would I go about checking that? There's nothing in the log about credentials; no errors or warnings. – Jools Jan 18 '17 at 22:34
  • 1
    I can reproduce the problem on my Windows 10 box. I'm just wondering if Visual Studio can simply run in a non interactive session. Maybe Microsoft just does not allow it for some reason (technical? licence?). I can't find any mention of this anywhere. This may be related to session 0 isolation: https://msdn.microsoft.com/en-us/library/windows/hardware/dn653293.aspx . Note msbuild is probably the easiest route but is not strictly equivalent (env variables, etc. are not the same). – Simon Mourier Jan 22 '17 at 10:49

4 Answers4

4

If you use msbuild instead of devenv then it will work

msbuild $sln /t:Rebuild /p:Configuration=Release;Platform=x64
Callan
  • 656
  • 3
  • 2
  • That would rebuild the entire solution rather than a project. See http://stackoverflow.com/questions/13915636/specify-project-file-of-a-solution-using-msbuild for the command line for project and http://stackoverflow.com/questions/12036112/msbuild-project-specific-targets-for-solution-does-not-work/12081931#12081931 for how that works. – ivan_pozdeev Jan 20 '17 at 12:56
  • I spotted that. I assume the equivalent to the question command would something like `msbuild $sln /t:"$project:Rebuild" /p:Configuration=Release;Platform=x64` – Jools Jan 20 '17 at 15:14
  • 3
    what about .vdproj extension ? MSBuild can't build this kind of setup project... any solution ? – Gianpolo Jan 31 '17 at 14:07
2

The task scheduler logs a user on with a non-interactive session. The same may go for your SSH session. This means the allocated heap size and allocatable memory size are smaller than for an interactive login. You might be running into memory limitations.

Either increase the allocated heap size (see also this question) or use a service account to run the compile job.

Community
  • 1
  • 1
Simmetric
  • 1,443
  • 2
  • 12
  • 20
  • If that was the issue, wouldn't you expect it to consistently fail when built via ssh or the task scheduler? What's puzzling is that it never fails to build via ssh or the task scheduler, so long as the user is also signed in at the instance the build command is run, regardless of when the task or ssh session began. Can sessions be dynamically switched between interactive and non-interactive? – Jools Jan 20 '17 at 15:08
  • 1
    If you're already logged in, there already is an interactive session and the task scheduler or SSH can just use that session. They certainly don't sign out your user account to start up a non-interactive session. – Simmetric Jan 20 '17 at 15:14
  • I tested increasing the heap size to the same as an interactive session, but it didn't change the behaviour for this issue. I'm fairly sure what I'm seeing must be specific to something devenv does on startup, as these few projects are part of a much larger compile job and they're consistently the only things to go wrong. – Jools Jan 23 '17 at 10:34
0

This is not an answer, but I encountered a similar problem on Visual Studio 2015 actually trying to build an UWP project:

Windows UWP build on Windows 10 machine with remote ssh login and cmake

Once I'm logged in, everything works fine, but using ssh it already fails at compiler checks.

Community
  • 1
  • 1
Clemens Arth
  • 86
  • 8
-1

make sure you have this option configuredenter image description here

Alex Honcharuk
  • 23
  • 1
  • 6
  • 2
    I have that set. Sorry that's what I meant when I said "windows task scheduler (set to work when not logged in". Also this isn't a problem with the task running. It runs, but the command fails. I get the same thing via ssh to. It seems to be independent of the task scheduler and something to do with devenv (VS) or Windows 10 issues. – Jools Jan 11 '17 at 14:08