* Make IDE0251 a suggestion
It fires in some very funky places like Dispose methods
where it's not _wrong_ but it would be _weird_.
* Put expected and actual in the right places for some tlbimp tests
* Explicit System.IO.Compression reference on framework
* Suppress the error PKV006 for Net 7.0, since we're intentionally dropping it
Co-authored-by: Jenny Bai <v-jennybai@microsoft.com>
Co-authored-by: Gang Wang <v-gaw@microsoft.com>
Update target framework in MSBuild and related places (consolidating MSBuild references).
Add NoWarn for deprecation warnings (#7902) and API-stability analyzer problems (#7903).
Fix a issues around crypto API simplifications on .NET Core spotted by new analzyers.
Co-authored-by: Rainer Sigwald <raines@microsoft.com>
I noticed an error of failing to find S.R.MLC if we deploy to the SDK since it isn't currently there. I think this should be made unnecessary for newer SDKs soon, but it'd still be useful for older SDKs, and it doesn't hurt.
Context
else if is a thing in powershell but only since about 3 months ago...which means that if you just updated powershell, the PR is unnecessary. This just means you don't have to be on the very latest version for it to work.
Testing
I used it
With Deploy-MSBuild.ps1
Only works if you're deploying to a folder that looks like *dotnet*sdk*
Note that this is a bit hacky, but I think that's fine for a script that is mostly used by us.
Testing
I tried deploying to a folder that looked like ...\dotnet\sdk\folder, and it put the Core assemblies in rather than Framework as desired.
Fixes#6075
### Context
Microsoft.IO.Redist brings some of the new .NET Core System.IO functionality to .NET Framework. In particular, enumeration in Microsoft.IO was optimized comparing to System.IO: new enumeration API was added and old one was improved. We consider it is beneficial to switch default file system enumeration to the old API from Microsoft.IO.Redist.
### Changes Made
- Added Microsoft.IO.Redist
- Default file system enumeration uses Microsoft.IO instead of System.IO
### Testing
Unit tests & DDRITs
### Notes
We should be wary of possible regressions. There were differences in behavior, see `.NET Framework only` notes in [doc](https://docs.microsoft.com/en-us/dotnet/api/system.io.directory.enumeratefiles?view=net-5.0). The change therefore is under change wave 17_0.
Fixes#6682
### Context
Deploy-MSBuild.ps1 does not properly copy files amd64 files into VS
### Changes Made
- Handle x64 files with their backup
- Add Microsoft.Common.tasks
- Fix for net6 - removing some files
### Testing
Locally
except in Common props, targets and tasks.
1. Remove all trailing spaces.
2. Fixup NewLine(s) where necessary
- Add New Line(s) between every block to make it clear.
- Remove unnecessary New Line(s) to reduce scrolling.
These are the files that would be touched by VS Editor later.
Separating the whitespace changes early on would help reviewers.
Changes Made
updated VS deploy script to copy more files needed during runtime
added option to break into the BuildManager via a new env var. This makes it super easy to debug msbuild running in devenv without having to copy over local bits
This is an attempt to fixmicrosoft/vstest#2282.
When sharing the terminal with child nodes, wait
for the children to terminate before exiting ourselves.
This avoids issues where the child changes terminal configuration
after our own exit.
Co-authored-by: Kirill Osenkov <github@osenkov.com>
When I tried the deployment script msbuild failed not finding the satellite assemblies. Apparently this happens when you're testing msbuild bits with new resources.
Quickbuild calls each project with `BuildProjectReferences=false`, which makes the main p2p target be `GetTargetPath` instead of the default (default target or the `ProjectReference.Targets`). This PR updates the target protocol for static graph to reflect this.
Unfortunately, Microsoft.Managed.targets was imported before the common targets which define `BuildProjectReferences`. So I split it up in before / after imports.
Adding a script, EnumerateMSBuild.ps1, which will output a file
containing all dll/exe files under the Visual Studio instances installed
on your machine. This can be helpful debugging support issues where
symptoms look like mismatched MSBuild versions.