Remove unneeded using statements #60
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Hi @Salmonz, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution! TTYL, DNFBOT; |
|
@Salmonz, Thanks for signing the contribution license agreement so quickly! Actual humans will now validate the agreement and then evaluate the PR. |
| @@ -8,7 +8,7 @@ | |||
|
|
|||
| using System; | |||
| using System.Diagnostics; | |||
| using System.Security.Permissions; // for SecurityPermissionAttribute | |||
| // for SecurityPermissionAttribute | |||
There was a problem hiding this comment.
Would you mind yanking this line as well :) It doesn't make sense anymore :)
|
Looks good to me barring the comment for SecurityPermissionAttribute |
|
Closing as duplicate of #31. There's a PR for this functionality in CodeFormatter right now. When that gets in, we can use it to format all the code now (and in the future). |
|
CodeFormatter PR for reference: dotnet/codeformatter#101 |
|
I closed the issue #21 so hopefully no further PRs get submitted between now and the CodeFormatter PR gets included. |
radical
added a commit
to radical/msbuild
that referenced
this pull request
May 28, 2018
* Revert "[RFC]: Add support for fallback search paths for Target frameworks" This reverts commit 0826df1. * GetReferenceAssemblyPaths: Add `TargetFrameworkFallbackSearchPaths` .. property. This specifies a list of ';' separated paths which are used as fallback search paths, for looking up the target framework, if could not be found in @rootpath. * Add $(TargetFrameworkFallbackSearchPaths) for looking up target .. frameworks. This contains ';' separated list of paths. When `GetReferenceAssemblyPaths` task will look for assemblies corresponding to a target framework, then it will try to find it in multiple locations: 1. $(TargetFrameworkRootPath) or the default path if $(TargetFrameworkRootPath) is '' 2. Each path in $(TargetFrameworkFallbackSearchPaths) * [tests] ToolLocationHelper_Tests: Move to use TestEnvironment .. in preparation for upcoming commits. * ToolLocationHelper APIs: Add support for target framework fallback .. .. search paths. `ToolLocationHelper.GetPathTo{StandardLibraries,ReferenceAssemblies}` look for the target framework in the path specified by @targetFrameworkRootPath parameter (roughly corresponding to the $(TargetFrameworkRootPath) property) or the default path. It would be useful to be able to look for these frameworks in more than one location. For example, in case of Xamarin products on OSX, mobile specific frameworks are installed in `/Library/Frameworks/Mono.framework/External/xbuild-frameworks` and the .NET ones are installed in `/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/xbuild-frameworks` . With support for fallback search paths, a lookup for a target framework will follow the order: 1. @targetFrameworkRootPath or default location if @targetFrameworkRootPath is '' 2. Fallback search paths APIs changed: GetPathToStandardLibraries(string targetFrameworkIdentifier, string targetFrameworkVersion, string targetFrameworkProfile, string platformTarget, string targetFrameworkRootPath) changed to => GetPathToStandardLibraries(string targetFrameworkIdentifier, string targetFrameworkVersion, string targetFrameworkProfile, string platformTarget, string targetFrameworkRootPath, string targetFrameworkFallbackSearchPaths = null) GetPathToReferenceAssemblies(string targetFrameworkIdentifier, string targetFrameworkVersion, string targetFrameworkProfile, string platformTarget, string targetFrameworkRootPath) changed to => GetPathToReferenceAssemblies(string targetFrameworkIdentifier, string targetFrameworkVersion, string targetFrameworkProfile, string platformTarget, string targetFrameworkRootPath, string targetFrameworkFallbackSearchPaths = null) New overload: GetPathToReferenceAssemblies(string targetFrameworkRootPath, string targetFrameworkFallbackSearchPaths, FrameworkNameVersioning frameworkName) - The reason for using a `targetFrameworkRootPath` parameter separate from the `targetFrameworkFallbackSearchPaths` is that we need to automatically fallback to a default path, which is being determined in code (`FrameworkLocationHelper.programFilesReferenceAssemblyLocation`). - Also, the parameter `targetFrameworkRootPath` roughly corresponds to the `$(TargetFrameworkRootPath)` property and changing that to have multiple paths would change it's meaning. * [mono] Set default $(TargetFrameworkFallbackSearchPaths) for osx - This sets up the $(TargetFrameworkFallbackSearchPaths) to point to `/Library/Frameworks/Mono.framework/External/xbuild-frameworks` on mono/osx. This location is used by Xamarin to install frameworks. The .net frameworks are available in usual default location. So, effectively, target frameworks are looked up, in order: 1. $(TargetFrameworkRootPath) or the default location, if $(TargetFrameworkRootPath) is '' 2. If not found in (1), then try to find it in the fallback search paths specified in $(TargetFrameworkFallbackSearchPaths) Note that we always add the `External` as the last fallback path on `$(TargetFrameworkFallbackSearchPaths)`. Rationale: When running on Mono, target frameworks are searched for in `$mono_prefix/lib/mono/xbuild-frameworks`, which becomes `/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/xbuild-frameworks`. This works, but has a problem when upgrading the Mono.framework package: a *new* `/Library/Frameworks/Mono.framework/Versions/@Version@` directory is created, so anything installed into the previous directory will be "lost". The file is still there, but xbuild will no longer find it. To address this upgrade scenario, Mono's xbuild also checks a fallback path: `/Library/Frameworks/Mono.framework/External/xbuild-frameworks` This location is not within a versioned framework directory, and thus files installed into it will survive Mono.framework package upgrades. This also allows overriding the root path to test in-tree builds of custom target frameworks. Simply changing `$(TargetFrameworkRootPath)` would mean that the in-tree builds of the custom frameworks would work but the default ones would not be found!
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Removed as per suggestion in #21