Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bump up msbuild to newer corefx versions #632

Merged
merged 12 commits into from
May 20, 2016
Merged

Conversation

cdmihai
Copy link
Contributor

@cdmihai cdmihai commented May 18, 2016

  • bump up corefx, build tools, and CLI
  • replaced TypeFilter usages with Func<Type, object, bool>
  • Removed Environment.GetCommandLineArgs
  • Replaced Assembly.Location with reflection access
  • Conditionally add / remove whitelisted property functions based on .net core availability
  • Delayed static property function receiver type resolution until the method name is known
  • Replaced MSBuild's implementation of Path.GetFullPath with the one in the .Net framework
  • Updated nuget framework monikers
  • Replaced explicit runtimes with nuget --infer-runtimes to get around Nuget's stricter restore

@cdmihai
Copy link
Contributor Author

cdmihai commented May 19, 2016

@dotnet-bot test OSX Build please

@rainersigwald
Copy link
Member

    /// Path.GetFullPath is slow and creates strings in its work: this version doesn't.

Can you update this comment with the new state of the world for 4.6.2 (?) and .NET Core?


Refers to: src/Shared/FileUtilities.cs:308 in b9a24b1. [](commit_id = b9a24b1, deletion_comment = False)

[Trait("Category", "netcore-osx-failing")]
[Trait("Category", "mono-osx-failing")]
public void InvalidPathAndMetadataItemFunction()
[PlatformSpecific(PlatformID.Windows)]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@rainersigwald
Copy link
Member

:shipit:

@cdmihai
Copy link
Contributor Author

cdmihai commented May 20, 2016

@dotnet-bot test this please

cdmihai and others added 5 commits May 20, 2016 15:05
For some weird reason beyond my Nuget comprehension it works now.
…til the method name is known

Types for the receiver of static property function calls resolved from
the type cache in AvailableStaticMethods only when they were types with
all of their methods whitelisted (thus appearing only with their type
name in the cache, not typeName::methodName). This caused partially
whitelisted types as File and Directory to always miss the cache and
resolve with Type.GetType()

On .net core this is a problem because namespaces are being moved out
from mscorlib to their own dlls, which causes Type.GetType to fail
because it assumes that namespace qualified types are from either the
current assembly, or from mscorlib. For example,
Type.GetType("System.IO.File") resolves on net46 but not on .net core.

To fix this, I delayed the type resolution for static invocations only
after the method name is known. This way, the code can construct the
method qualified name and properly search the cache for the type.

Other edits:
- refactored Function.ExtractPropertyFunction to use disjunct
construction branches for each type of property function, rather than a
soup of intertwined logic. Should make future refactoring easier (i.e.,
creating some builder subclasses for each property function type)

- added a FunctionBuilder type that aggregates all the function parts
needed for a property function and changed the code to use it. This way,
control flow gets decoupled from a partially constructed function which
allows me to easily change the order in which functions parts get
constructed. Downside is the function state duplication.

- added convenience methods in the AvailableStaticMethods class
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants