Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sample doesn't build from MSBuild #74

Open
dfederm opened this issue Jul 18, 2018 · 2 comments
Open

Sample doesn't build from MSBuild #74

dfederm opened this issue Jul 18, 2018 · 2 comments

Comments

@dfederm
Copy link

dfederm commented Jul 18, 2018

Repro:

E:\service-fabric-dotnet-getting-started\src\GettingStartedApplication\GettingStartedApplication> msbuild /t:Package

Error:

"E:\service-fabric-dotnet-getting-started\src\GettingStartedApplication\GettingStartedApplication\GettingStartedApplication.sfproj" (Package target) (1) ->
"E:\service-fabric-dotnet-getting-started\src\GettingStartedApplication\ActorBackendService\ActorBackendService.csproj" (default target) (2:2) ->
"E:\service-fabric-dotnet-getting-started\src\GettingStartedApplication\ActorBackendService.Interfaces\ActorBackendService.Interfaces.csproj" (default target) (6:2) ->
(_CheckForInvalidConfigurationAndPlatform target) ->
  C:\Program Files (x86)\Microsoft Visual Studio\Preview\Enterprise\MSBuild\15.0\bin\Microsoft.Common.CurrentVersion.targets(780,5): error : The OutputPath property is not set for project 'ActorBacke
ndService.Interfaces.csproj'.  Please check to make sure that you have specified a valid combination of Configuration and Platform for this project.  Configuration='Debug'  Platform='AnyCPU'.  You ma
y be seeing this message because you are trying to build a project without a solution file, and have specified a non-default Configuration or Platform that doesn't exist for this project. [E:\service
-fabric-dotnet-getting-started\src\GettingStartedApplication\ActorBackendService.Interfaces\ActorBackendService.Interfaces.csproj]


"E:\service-fabric-dotnet-getting-started\src\GettingStartedApplication\GettingStartedApplication\GettingStartedApplication.sfproj" (Package target) (1) ->
"E:\service-fabric-dotnet-getting-started\src\GettingStartedApplication\StatelessBackendService\StatelessBackendService.csproj" (default target) (4:2) ->
"E:\service-fabric-dotnet-getting-started\src\GettingStartedApplication\StatelessBackendService.Interfaces\StatelessBackendService.Interfaces.csproj" (default target) (7:2) ->
  C:\Program Files (x86)\Microsoft Visual Studio\Preview\Enterprise\MSBuild\15.0\bin\Microsoft.Common.CurrentVersion.targets(780,5): error : The OutputPath property is not set for project 'StatelessB
ackendService.Interfaces.csproj'.  Please check to make sure that you have specified a valid combination of Configuration and Platform for this project.  Configuration='Debug'  Platform='AnyCPU'.  Yo
u may be seeing this message because you are trying to build a project without a solution file, and have specified a non-default Configuration or Platform that doesn't exist for this project. [E:\ser
vice-fabric-dotnet-getting-started\src\GettingStartedApplication\StatelessBackendService.Interfaces\StatelessBackendService.Interfaces.csproj]

    0 Warning(s)
    2 Error(s)

Time Elapsed 00:00:02.23

Looking at those projects, they only define OutputPath for Platform x64, but AnyCPU is the Platform being used.

@vipul-modi
Copy link
Contributor

@vturecek

@dfederm
Copy link
Author

dfederm commented Jul 18, 2018

I was able to mitigate by adding <Platform>x64</Platform> to WebService.csproj.

Although both interfaces projects also have incorrect defaults for Platform. They default to AnyCPU despite only having config for x64. The csproj's need to be updated for those as well.

For the WebService.csproj issue, it looks like GetServiceProjectReferences is trying to read the platform and finds "AnyCPU" by default so sets it explicitly to that when building it. Then all recursively references also build with that platform, which isn't the intent.

As an aside, GetServiceProjectReferences seems to be loading up the projects using the MSBuild API, which is just terrible for perf. You're already in the context of MSBuild, so just pass the information along rather than spinning up yet another MSBuild evaluation per referenced project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants