Open ClxS opened 3 years ago
This sounds similar to an issue in the C++ projects, what happens if you specify:
filter { "platforms:platform_a" }
architecture "x64"
filter {}
@samsinsane Same issue, in that scenario I end up with the ActiveCfg being set to a value like this:
....ActiveCfg = Debug platform_a|x64
@ClxS Thanks for testing that, I might be mixing up two different problems that are both related to unknown platforms. Sorry that it didn't end up helping.
Before opening a new bug report, please read Reporting Bugs and consider if this is something you can contribute yourself. If this a new bug, help us help you by filling in the template below.
What seems to be the problem? The ActiveCfg and Build0 properties are invalid when generating a solution file containing a .NET Core project. When generating a .NET Core project, the solution contains activeCfg/build.0 entries in this format:
{E3D5870B-4FDF-877C-D85A-9E7C4463937C}.Debug|PcDx11_x64.ActiveCfg = Debug PcDx11_x64|x64
This format works for .NET Framework projects, but does not for .NET Core. It causes an odd bug in Visual Studio where it'll skip projects, despite it being marked for build in the configuration manager. It seems that in .NET Core it has gotten stricter with the config and platform requirements.
What did you expect to happen? Them to be valid. As they are the projects are not buildable in Visual Studio. This is not fixable via the Visual Studio UI and can only be hacked to work by manually changing the sln file.
What have you tried so far? This local override works.
It forces the configuration to be set to either Release or Debug. As I mentioned on the old issue... How should this be handled? The above feels like a hack, but I can't think of a better solution.
How can we reproduce this?
What version of Premake are you using? 1aeb39dfcef8d5d9fdb893c95bd6d3c6ad150cb6
Anything else we should know?
(You can now support Premake on our OpenCollective. Your contributions help us spend more time responding to issues like these!)