You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With #3398, we are now building powershell core via MSBuild with our building script. However, it seems not working properly in Visual Studio 2017. We need to make it possible to build powershell in VS2017 as well.
The term "Platform" sounds like the right one to use, but it seems always indicating the CPU architecture based on my limited MSBuild experience, for example, Any CPU, x64, and x86.
And we have another problem -- with the current project files, dotnet pack will generate a NuGet package that only contains assemblies built for windows, which cannot be used reliably on Linux. I wonder if it's possible that we can change the .csproj somehow to make dotnet pack produce a single NuGet package that contains both win and unix assemblies. #3417 is tracking it.
Is changing to "Platform" a possible direction? Do you have some resources on the differences between "Configuration" and "Project" in the new MSBuild from .NET Core SDK?
Platform may be what we choose. LinuxX64 for example.
They are just monikers to give builders an easy way to set different settings based on Config and platform.
C++ has had Win32 and x64 while .NET has used AnyCPU, x86 and x64. But I think this traditionally has been Windows specific, so instead of saying Win-x86, they just went with the shorter alternative.
I haven't had much time to dig into the changes with the new msbuild. Seems nice and clean though.
Please, please, this. I am loathe to return to building software like it's 1993. I already had that life. I just wasted three hours trying to make anything work at all in VS 2017 15.3-pre (supposedly it understands net standard 2.x) and it's just a confusing mess.
Reacted by Keith Hill, Bobby Cannon, Andrew Savinykh, Kelly Adams, Gavin, Pharmhaus.Net and inoperable
In .Net Core 3 they re-implemented some of the resgen functionality but usage within the csproj from command line and VS is not working well for non-WinForms projects, I opened an issue with them but once that is done, we could potentially use the functionality baked into dotnet build soon
We already moved ResGen to csproj.
Only TypeGen is still out of csproj that is required for VS works well. We could do the move as only MSFT team approve this.
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commented on Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commented on Nov 23, 2023
Activity
Migrate from project.json to MSBuild (#3398)
powercode commentedon Mar 24, 2017
Should we think about what is a Configuration and what is a Platform?
Linux is a config today, but it seems more reasonable to treat it as a platform.
I have a branch, https://github.com/powercode/PowerShell/tree/vs2017-build, where I can build with vs2017, but it is untested on Linux/Mac and from the command line.
daxian-dbw commentedon Mar 24, 2017
The term "Platform" sounds like the right one to use, but it seems always indicating the CPU architecture based on my limited MSBuild experience, for example,
Any CPU,x64, andx86.And we have another problem -- with the current project files,
dotnet packwill generate a NuGet package that only contains assemblies built for windows, which cannot be used reliably on Linux. I wonder if it's possible that we can change the .csproj somehow to makedotnet packproduce a single NuGet package that contains both win and unix assemblies. #3417 is tracking it.Is changing to "Platform" a possible direction? Do you have some resources on the differences between "Configuration" and "Project" in the new MSBuild from .NET Core SDK?
powercode commentedon Mar 27, 2017
Platform may be what we choose. LinuxX64 for example.
They are just monikers to give builders an easy way to set different settings based on Config and platform.
C++ has had Win32 and x64 while .NET has used AnyCPU, x86 and x64. But I think this traditionally has been Windows specific, so instead of saying Win-x86, they just went with the shorter alternative.
I haven't had much time to dig into the changes with the new msbuild. Seems nice and clean though.
iSazonov commentedon Mar 27, 2017
I wonder how .Net Core resolve the same for itself packages? Can we use the same?
iSazonov commentedon Mar 28, 2017
Staffan Gustafsson (@powercode) Could you make PR with your vs2017 sln file?
oising commentedon Jun 1, 2017
Please, please, this. I am loathe to return to building software like it's 1993. I already had that life. I just wasted three hours trying to make anything work at all in VS 2017 15.3-pre (supposedly it understands net standard 2.x) and it's just a confusing mess.
iSazonov commentedon Jun 1, 2017
I've already started taking little steps in this direction, but Dongbo Wang (@daxian-dbw) too busy these days to do the PR review.
BobbyCannon-Quantros commentedon Sep 13, 2017
It's been a few months... any progress on this?
oising commentedon Oct 18, 2017
Ping pong poong.
I (and many others I'm sure) want it to build in VS 2017 so we can use ReSharper and other tools.
BobbyCannon-Quantros commentedon Oct 18, 2017
Plus + 1000 Oisin Grehan (@oising)! You know... use Visual Studio. :)
SteveL-MSFT commentedon Oct 19, 2017
This isn't something we're prioritizing for 6.0.0, but we can add it to the 6.1.0 queue although that itself is growing quite large...
powercode commentedon Oct 20, 2017
I just noticed that if I add a property
then visual studio understands the project formats.
Sorry that I haven't been pushing this. So silly, I make it work locally, but never get around to pushing it.
iSazonov commentedon Oct 20, 2017
Staffan Gustafsson (@powercode) If you haven't free time - put a link on the file so everybody can grab, test and push PR.
18 remaining items
bergmeister commentedon Nov 17, 2019
In .Net Core 3 they re-implemented some of the resgen functionality but usage within the csproj from command line and VS is not working well for non-WinForms projects, I opened an issue with them but once that is done, we could potentially use the functionality baked into dotnet build soon
xtqqczze commentedon Apr 28, 2020
Related: #12373
iSazonov commentedon Apr 29, 2020
We already moved ResGen to csproj.
Only TypeGen is still out of csproj that is required for VS works well. We could do the move as only MSFT team approve this.
kyanha commentedon Sep 17, 2020
Can TypeGen be invoked as a separate tool from the VS2019 prebuild commands configuration?
iSazonov commentedon Sep 18, 2020
Kyle H (@kyanha) You could run Start-PSBiuld -TypeGen there. (pwsh -command ....)
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 23, 2023
This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.
ThuggGit commentedon Jun 25, 2025
Migrate from project.json to MSBuild (PowerShell#3398)