Msbuild does not work

I have a freestyle project set up. Right before I invoke msbuild in a batch file, I issue “dir” to verify the solution file is present. When I invoke msbuild using this .sln file as the project/solution to build, it errors with “Project file does not exist.” That doesn’t make sense. Previously I used an actual “Build a Visual Studio Project…” step and got the same error. Whether from a batch file or ran directly, the result is the same.
I’m stumped. Anyone have an idea for a solution? Here’s the relevant output from the console window.

Volume in drive C has no label.
Volume Serial Number is 8C2E-DEBB

Directory of C:\Windows\System32\config\systemprofile\AppData\Local\Jenkins.jenkins\workspace\GameServer\GameServerKit

12/20/2022 10:43 AM [DIR] [this]
12/20/2022 10:43 AM [DIR] [parent]
12/20/2022 10:43 AM 579 BuildAll.bat
12/20/2022 10:43 AM [DIR] GameServerKit
12/20/2022 10:43 AM 230,082 GameServerKit.sln
12/16/2022 04:39 PM 519 preBuildScriptForSolution.bat
12/19/2022 02:44 PM 293 versioner.bat
4 File(s) 231,473 bytes
3 Dir(s) 25,485,660,160 bytes free


C:\Windows\System32\config\systemprofile\AppData\Local\Jenkins.jenkins\workspace\GameServer\GameServerKit>REM This should exist and be running from the GameServer\GameServerKit folder

C:\Windows\System32\config\systemprofile\AppData\Local\Jenkins.jenkins\workspace\GameServer\GameServerKit>REM Purge unique files built last

C:\Windows\System32\config\systemprofile\AppData\Local\Jenkins.jenkins\workspace\GameServer\GameServerKit>del …\GWService\GWService\bin\Release\GWService.*
The system cannot find the path specified.

C:\Windows\System32\config\systemprofile\AppData\Local\Jenkins.jenkins\workspace\GameServer\GameServerKit>copy GameServerKit\GameServerKit-Release.isproj GameServerKit\GameServerKit.isproj /y
1 file(s) copied.

C:\Windows\System32\config\systemprofile\AppData\Local\Jenkins.jenkins\workspace\GameServer\GameServerKit>msbuild.exe -p:Configuration=Release GameServerKit.sln
Microsoft (R) Build Engine version 15.9.21+g9802d43bc3 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

MSBUILD : error MSB1009: Project file does not exist.
Switch: GameServerKit.sln

Seeing the contents of your BuildALL.bat file would be useful in this particular case.

Here is the contents of BuildAll.bat. Note that two dots are displayed as three dots, I don’t know how to prevent that.
I also tried putting the solution filename ahead of the parameter (per their help boilerplate), same result.

REM This should be ran from the GameServer\GameServerKit folder
REM Purge unique files built last
del …\GWService\GWService\bin\Release\GWService.*
copy GameServerKit\GameServerKit-Release.isproj GameServerKit\GameServerKit.isproj /y
msbuild.exe -p:Configuration=Release GameServerKit.sln
REM Purge unique files built for Release
del …\GWService\GWService\bin\Release\GWService.*
copy GameServerKit\GameServerKit-Secure.isproj GameServerKit\GameServerKit.isproj /y
msbuild.exe -p:Configuration=Secure GameServerKit.sln

workspace/GameServer/GameServerKit/GameServerKit isn’t confusing at all.

That aside. msbuild is finding your solution just fine which suggests that the solution is referencing the project file differently than you think it does. Generally you don’t need separate project files to hold multiple configurations. A single configuration file can contain multiple configurations. I’d guess that the .SLN and/or the .ISPROJ file are at fault here.

Have you tried this InstallShield build by hand?

I can run BuildAll.bat on my dev system, in an identical file structure, and it builds both Release & Secure builds perfectly. Selecting build type “-p:…” does not affect the InstallShield build type (in GameServerKit.isproj, AFAIK), it builds whatever is selected within that project file, which is why I have two versions, and copy in the one corresponding to the build I want. Each generates a different output exe filename which tells me which it built. That would seem to be an omission in how InstallShield sets up their projects: build type specified by the user, not by the builder or builder parameter. We are having other issues with InstallShield 2022 and VS 2022, so have had to use IS2019 & VS2019, issues we’ve made them aware of.

If that is the case, why does the error specifically say “Switch: GameServerKit.sln?” If you’re suggesting that it’s complaining about a project within the solution, I will have to spend a considerable amount of time trying to figure out which one, out of the 30 or so in this solution. That’s Microsoft’s problem, not Jenkins’, but it makes the CI/CD process a bear to get working correctly.
I have another project to work on, after which I will attempt to figure out more specifically what msbuild is complaining about, and comment further if I find a solution. To reiterate, it builds fine on my dev system, using a fresh clone of the repo. If I don’t replace the .isproj file (or manually update between builds), I get the same exe for both builds.
Your assistance is appreciated.

okay weird. What other differences (apart from Jenkins) are there between your dev machine and the Jenkins agent? MSBuild matches? Would parameter order make a difference? the msbuild documentation says msbuild [switches] projectfile and then proceeds to document examples as msbuild projectfile [switches]

for my own systems, I have the Microsoft Build Tools (not Visual Studio) and the InstallShield Command Line Builder installed.

That’s going to not have things a full VS install would have, but it should still work in most cases.

Is it possible that the Jenkins agent does not have sufficient permissions on the sln file? If it cannot read the attributes to check whether it has a file or a directory, that might cause the error.

Related MSBuild source code:

@kon That code in MSBuild looks like it throws an error if the filespec I give it is not a folder, which is strange. I use the exact same batch file locally and it works fine.
I see that we can configure MSBuild settings under Global Tools Configuration. We have 2017 & 2019 defined, but in setting up the project configuration, it doesn’t allow you a choice on which to use, if any. I have to manually add the path "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin" in order for it to find MSBuild at all.
It is now running the correct version of MSBuild. I see this locally and in the Jenkins build log (except minus the error locally).
Microsoft (R) Build Engine version 16.11.0+0538acc04 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

MSBUILD : error MSB1009: Project file does not exist.
Switch: GameServerKit.sln

Actually my local version is newer, “16.11.2+f32259642”. I have no idea how to update the version on Jenkins. I’ll look into that.
It’s difficult to diagnose issues. It’s not like I can drop into a command window and look around (that I know of).

I have admin role, so should not have access issues.

If you are admin on the Windows OS of the agent computer, you could set up Process Monitor to monitor what MSBuild.exe does with sln files. Perhaps that would reveal some error.

I have been told by a coworker, who worked on a different Jenkins project, that the “.jenkins” part of my working path (C:\WINDOWS\system32\config\systemprofile\AppData\Local\Jenkins.jenkins\workspace) is a hidden folder, and msbuild can’t see files there. Does anyone have additional information on this? Why does git clone a repo into child folders of this path, but msbuild.exe can’t see files there? That makes no sense!
My coworker’s solution was to set up and build everything in D:\jenkins_workspace. I will try that if I can’t get any additional information on this strange problem.

Is this build running on an agent or on the controller? If running on the controller, it looks like Jenkins was not installed with the recommended setup (using an actual user for the service login instead of using Local System). With Local System as the account running the service, it has a lot of problems with permissions to directories and such. I highly recommend setting up a specific user for the controller service. If running on an agent, it is a similar issue if you are running the agent process as a service. The Local User “account” does not function the same as a normal user account.

I am new to the company and to Jenkins. I found out that we DO have our own Jenkins server. A coworker says he installed it, and doesn’t recall what settings were used, other than the defaults. Other colleagues have said that “.jenkins” in a path makes it “hidden” to certain processes, like msbuild. Is Jenkins supposed to set “.jenkins” as part of the default home directory? The existing Jenkins jobs/projects all circumvent this “hidden” folder issue by cloning & building from the D drive, which means we can’t use built-in stuff like git. These projects use batch/shell commands to clone & update source code. I am continuing to investigate. Changing the home folder is not a trivial task, and may break the handful of other projects/jobs that are set up.

It works if the path of the solution does not have “.jenkins” in it. I was told by colleagues that this is considered a “hidden” folder when it comes to msbuild. I can view the folder without issue, run “dir” commands, etc. Something is strange about how “.jenkins” is handled.

I don’t think msbuild handles . directories any differently than Windows in general, which is to say not at all. Can you answer whether this is running on an agent or not? Can you add additional commands to the build so you can try doing a “dir” command and some other things on the workspace directory? Also, remember that the user that Jenkins is running the build as is not the same as YOUR user account, so anything you try as your user account will not show any of the same issues that might occur when Jenkins is running things as Local System (which is what looks like is happening). So any path or environment variables that you have set in YOUR login are not the same as what Jenkins is running as when it is running as Local System

Since I have access to the Jenkins server, I RDC’ed directly into it. I can go to the folder Jenkins uses (C:\Windows\System32\config\systemprofile\AppData\Local\Jenkins\.jenkins\workspace\GameServer\GameServerKit) (the folder is correct here, had to use two ‘\’ before the period to show one) and run the batch file I use in the Jenkins project. It fails with the same error on msbuild, “Project file does not exist.” I verified that the solution file (passed to msbuild) resides in this directory. If I set up the repo in a different folder, it finds and builds the solution. The Jenkins process works the same as what I get in a command window, so the problem appears to be with msbuild. nuget restore commands do not have a problem with this path.
I have run DIR and SET commands in the Jenkins project and I don’t see anything out of the ordinary.
I don’t know if this is running on an agent or not, how would one tell? I have full access to the Jenkins machine. I run the project from a different machine, hitting Jenkins from a browser at its IP:8080. I can also run it on the Jenkins server in Chrome on localhost:8080.

I personally don’t think it has anything to do with the . because on my old server, my JENKINS_HOME is C:\Users\myuser.jenkins, so I think perhaps it has more to do with being in the system profile area, but I could be wrong.