I think we should add TargetFramework property to PowerShell.Common.props not every csproj.

The whole point of having it in every project is to work around the issue that visual studio issue doesn't understand TargetFramework from imported files.

The property already is in PowerShell.Common.props.

I wonder how and why the trick works.

My guess is that they explicitly look for the property in the file, but using the full logic for evalutating it's value.

By doing this, we can at least keep the value consistent, and updatable in one place, while still being able to use Visual Studio.

I agree it isn't ideal, and it should be removed if VS fixes the issue.
I haven't checked where this can be reported. @PowerShellTeam anyone got any good connections in devdiv?

It would be good to have a comment from VS team that is best way in the case.

And maybe a comment in the csproj files why that strange construct is used.

@this issue looks to be related to the issue experienced here:

dotnet/project-system#1358

@powercode
I have tried your fork on my local machine. I ran Start-PSBootStrap, installed the .Net Core SDK 2.0.0 (since this is the state of your fork), ran a dotnet restore on the solution and had to pre-build it using Start-PSBuild. Then trying to build in VS still yields some errors:

Also I have seen that all projects are practically empty in Solution Explorer because in all the projects source code is marked as <Compile Remove=*.cs>. We need to be able to see the source code files in VS in order for it to be useful. How does the whole build system work if the source code files are removed from compilation, does the TypeCatalogGen do all that work?

@bergmeister That is wierd. That reference is removed in c8e4192

Are you sure you are running on my branch? Without these changes, all source files are hidden in Visual Studio, but with the TargetFrameworkVersion, it seems to work as expected.

@powercode Sorry, I was caught out by cloning your fork but being on the wrong branch. I can see the files now in solution explorer but building only seems to work if the repo is pre-build via command line via Start-PSBuild (just running Start-ResGen is not sufficient). I am using using VS 15.5.2 on Win10.

@powercode : can you please downstream changes from master to your fork since GitHub does not allow to have multiple forks so that people can start using it already. What timeline do we expect until this is merged into master @TravisEz13 ?
Downstreaming can be done as follows:

cd $PowerShellCheckout
git checkout vs-csproj
git remote add upstream https://github.com/PowerShell/PowerShell.git
git pull upstream master
git push

@bergmeister , @daxian-dbw is assigned to this PR.
I've restarted Travis-CI linux due to markdown test failures due to out of date code. hopefully github will remerge on it's own.

Rebased on master.

@markekraus Do you use Visual Studio? Could you review the PR?

@iSazonov I have Visual Studio, but I'm not familiar with it (I use VS Code). You are better off asking for a review @rkeithhill and/or @bergmeister. I believe they are both familiar with Visual Studio.

I can take a look again since I have to use VS nearly the whole day but my review from a user's perspective is already here
But it definitely makes sense if others chip in as well.

@daxian-dbw Could you please continue with the PR?

We need to actually use the changes for a few days to get a feel. I suggest all active maintainers to try out the changes. /cc @PowerShell/powershell-maintainers
Also, for anyone who want/like this PR, please also try out the changes and help bring up issues. The more eyes the merrier :)

1. Step

git clean -fdX
run Build in VS

========== Rebuild All: 0 succeeded, 13 failed, 0 skipped ==========

I found related dotnet/project-system#2129

2. Step

dotenet restore
run Build in VS

We see two errors "Invalid Resx file" with xsd.
src\System.Management.Automation\resources\CmdletizationCoreResources.resx
src\Microsoft.PowerShell.Commands.Management\resources\CmdletizationResources.resx

3.Step

After fix this Resx files
run Build in VS

visual studio cannot start debugging because the debug target is missing exe

We haven't compiled resources.

4. Step

run our RexGen
run Build in VS

We haven't "InitializeTypeCatalog"

5. Step

run our TypeGen
run Build in VS

Now we build well.

6 Step

run from VS
or
run debugging in VS

Get error: visual studio cannot start debugging because the target '\pwsh.exe' is missing
Really there is no thefile - only pwsh.dll

VS2017trace.txt

Until we move resource generation into a msbuild task, we will have to complete a cmdline build first.

I set up a publishing rule to publish a build before debugging, and manually configured the debug target.
Debugging is generally not something you share, since you often start with different arguments.

I already push PR #3870 for TypeGen but it don't approved a long time. I already patched our temp utility for ResGen in PR #3918 and ready to push PR to run it by MSBuild.

I created a new PR based on this one. #6546 I've verified it works and the fix is simpler. I based it on your fix. I think we should probably close this one. Thanks, Travis . Thanks for your help.