ASP.NET Core Web API: Program does not contain a s

问题:

I am working on an ASP.NET Core Web API that references other projects (csproj) within a large solution. The ASP.NET Core Web API builds in Visual Studio 2015 and using msbuild in a command prompt "on my machine" :-)

msbuild SomeWebAPI.xproj

  Compilation succeeded.
  33 Warning(s)
  0 Error(s)

Time elapsed 00:00:01.7740626

Done Building Project 
.
.
Build succeeded.

Problem is it doesn't build on our build-server. Same msbuild-command, same msbuild-version, different result:

msbuild SomeWebAPI.xproj

error CS5001: Program does not contain a static 'Main' method suitable for 
an entry point [D:\TeamCity\buildAgent\work\8120f5584932b96b\S
SomeWebAPI\SomeWebAPI.xproj]

Compilation failed.
  0 Warning(s)
  1 Error(s)

Time elapsed 00:00:03.3428080

Done Building Project 

"D:\TeamCity\buildAgent\work\8120f5584932b96b\SomeWebAPI\SomeWebAPI.xproj" 
(default targets) -- FAILED.

Build FAILED.

Being a webapi it makes no sense to add a static 'Main' method and the fact that it works "on my machine" but not on our build-server puzzles me. Any suggestions? Please let me know, if you need more info, code, project.json or anything that could help you lead me to an answer :-)

Update:

Based on @Tseng 's comment I added a main method to the startup:

// Entry point for the application.
public static void Main(string[] args)
{
    var host = new WebHostBuilder()
        .UseContentRoot(Directory.GetCurrentDirectory())
        .UseIISIntegration()
        .UseKestrel()
        .UseStartup<Startup>()
        .Build();

    host.Run();
}

But then I cannot build the project on my own machine:

C:\test\path\SomeWebAPI\Program.cs(8,28): error CS0017: Program has more 
than one entry point defined. Compile with /main to specify the type that 
contains the entry point. [C:\test\path\SomeWebAPI\SomeWebAPI.xproj]

That pointed out the Program.cs with an almost exact copy of the main method above. Apparently the project template I used a couple of months ago put the main method in the Program class. Obviously, @Tseng is right, and I was wrong. Unfortunately, that set me back to the original question. Why does the project build on "my machine" but not on our build-server? The obvious answer, "the 'Main' method is missing is in fact correct, given that, for some reason, the Program.cs file wasn't checked out from source control by TeamCity. But that's another story...

回答1:

Did you used msbuild from the "MSBuild Command Prompt for VS2015"?

If that is the case the environment variables in your build server may need some configuration.

MSBuild Command Prompt uses this command line (%comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\VsMSBuildCmd.bat"") to initialize the environment.

You may need to prepare the command line environment in your build server in order to get the same result.

回答2:

It turs out the answer lies outside the code, and not related to msbuild but to realise that I had to go through a few more steps. Based on @Tseng 's comment I added a main method to the startup:

// Entry point for the application.
public static void Main(string[] args)
{
    var host = new WebHostBuilder()
        .UseContentRoot(Directory.GetCurrentDirectory())
        .UseIISIntegration()
        .UseKestrel()
        .UseStartup<Startup>()
        .Build();

    host.Run();
}

But then I could not build the project on my own machine:

C:\test\path\SomeWebAPI\Program.cs(8,28): error CS0017: Program has more 
than one entry point defined. Compile with /main to specify the type that 
contains the entry point. [C:\test\path\SomeWebAPI\SomeWebAPI.xproj]

That pointed out a Program.cs with an almost exact copy of the main method above. Apparently the project template I used a couple of months ago put the main method in the Program class. Obviously, @Tseng is right, and I was wrong. Unfortunately, that set me back to the original question. Why did the project build on "my machine" but not on our build-server? The obvious answer, "the 'Main' method is missing" is in fact correct, given that, for some reason, the Program.cs file wasn't checked out from source control by TeamCity. A clean checkout in TeamCity solved the problem.