Remove requirement for adding project to libraries-packages file#46180
Remove requirement for adding project to libraries-packages file#46180Anipik wants to merge 2475 commits intodotnet:release/5.0from Anipik:servicing
Conversation
|
Tagging subscribers to this area: @safern, @ViktorHofer Issue DetailsWorking towards #46178 This changes helps developers to set ServicePackage Msbuild property to enable building of the package.
|
There was a problem hiding this comment.
Dynamic dependencies aren't supported by msbuild static graph hence this will introduce yet another blocker to adopt static graph build (static graph restore is already enabled).
I think we should instead use existing shipping packaging infrastructure from the SDK which allows a project to set IsPackable to control if a package should be generated.
There was a problem hiding this comment.
Yeah using IsPackable would be more intuitive as we could just set IsPackable=false in Directory.Build.props and then packages that we need to ship we would set them as IsPackable=true.
There was a problem hiding this comment.
And as I just saw that this PR targets release/5.0, we should do the same in master then.
There was a problem hiding this comment.
I gave this more thought and I believe I was wrong when I said that IsPackable should be used in servicing cases. IsPackable determines if a project is packable per-se, which controls if the Pack target is invokable on projects that import NuGet target files.
During the transition from pkgproj to csproj files, csproj files will be annotated with <IsPackable>true</IsPackable> to express that they are packable via the NuGet pack task instead of via the Microsoft.Dotnet.Built.Task.Packaging package. Overloading the semantic of IsPackable with IsServiceable will cause problems onwards, hence I believe the addition ServicePackage property makes sense, even though I would rename it to <GeneratePackage /> to make it usable for runtimelab as well.
There was a problem hiding this comment.
I implemented your proposal in master via #46447. It allows filtering on a project level instead of at traversal time. A nice side-effect of this work is that incremental servicing via solution files now works as well (instead of files that use Microsoft.Build.Traversal SDK in which you can apply conditions per P2P).
* Optimize Activity Ids * Generate long random numbers and make the generator object a threadstatic * Addnew line at the end of the file * Update the Random number generator * Fix Full Framework failure * Address the feedback regarding ranomizing Guid bits * address more Feedback * Address more feedback
Looks like it was never bumped to bring in dotnet/core-eng#10033 (comment)
…d net461 (#46458) * Reduce allocations in System.Threading.Channels for netstandard2.* and net461 System.Threading.Channels.AsyncOperation<TResult> is well optimized for .NET Core, but there are no optimizations for .NET Standard 2.0 and .NET Framework. They use the same code as .NET Standard 1.3. * Remove execution flow suppression as redundant * Rollback QueueUserWorkItem
'sisxth' -> 'sixth' Fixes #47292
* Exporting DotNetRuntimeInfo from singlefilehost * move runtimeinfo into a separate lib * enable runtimeinfo on macOS * export only runtimeinfo * fix FreeBSD build * revert DLLEXPORT change
* Parse method call chain model file and resolve methods * Resolve methods from Azure profile trace building a list of caller->callees with counts to use in compilation heuristics * Resolves the two main forms of methods we see in the traces: ``` System.Core.ni.dll!System.Linq.Enumerable+WhereSelectEnumerableIterator`2[System.__Canon,System.__Canon].MoveNext Microsoft.Azure.Monitoring.WarmPath.FrontEnd.Middleware.SecurityMiddlewareBase`1+<Invoke>d__6[System.__Canon]!MoveNext ```
…name contains android (#47045) Co-authored-by: Steve Pfister <steve.pfister@microsoft.com>
During my work on switching over framework library crossgenning to use Crossgen2 I noticed that jitinterface is missing the file version information. This change fixes the issue. Thanks Tomas
* Improved logger for the AOT compiler. The logic is mostly taken from IL Linker where prople spent a bunch of time on it. * Bunch of other changes.
This PR intentionally does not include any of the modifications on top of them or other files that will be needed to wire them up to the build.
|
@Anipik I think you accidentally included master commits here. |
* Crossgen2 presently abuses the `CORINFO_SIG_INFO` pSig field to pass a handle representing a managed method signature object which the JIT passes back to us later in compilation. This field is for byte arrays and causes problems with SuperPMI which rightly doesn't know how to interpret a zero-length buffer whose pointer is set. * Introduce a new field ,`methodSignature` where we pass the handle back to the JIT. This pattern saves us from allocating and pinning a byte buffer for signatures, something the native code VM and Crossgen1 don't have to worry about. * Add strongly typed `ObjectToHandle` and `HandleToObject` methods for `CORINFO_MODULE_STRUCT_` <=> `MethodIL` and `MethodSignatureInfo` <=> `MethodSignature`. * Add SuperPMI support for CORINFO_SIG_INFO.methodSignature Co-authored-by: Bruce Forstall <brucefo@microsoft.com>
… on browser build (#47789) * Remove logic for removing TFM target supported attributes for browser build, use latest analyzer
…Library.*Load* on Mono. (#47705) Handle NativeLibrary.GetExport on libs loaded with Interop.Kernel32.LoadLibraryEx. #47013 changed how kernel32.dll and Ws2_32.dll gets loaded on Windows. Instead of loading using NativeLibrary.Load these system libraries are now loaded directly using LoadLibraryEx, but symbols are still handled through NativeLibrary. This short-circuits some logic in Mono that assumes all libraries gets loaded through NativeLibrary.Load. Fix adds ability to use passed in HMODULE when not finding a matching library in our native library cache and use it directly, inline with CoreClr behavior. * Handle NativeLibrary GetExport/Free using IntPtr library OS handle xplat. * Disable additional System.Drawing.Common tests due to missing COM support.
* Use PAL_JITWriteEnable in debug/ee/controller.cpp * Fix breakpoint exception handling on macos * Fix Arm64SingleStepper for osx W^X * Fix DebuggerHeapExecutableMemoryPage for W^X * Fix DebuggerEval::DebuggerEval() during W^X
* Update dependencies from https://github.com/mono/linker build 20210201.1 Microsoft.NET.ILLink.Tasks From Version 6.0.0-alpha.1.21079.1 -> To Version 6.0.0-alpha.1.21101.1 * Update dependencies from https://github.com/mono/linker build 20210201.2 Microsoft.NET.ILLink.Tasks From Version 6.0.0-alpha.1.21079.1 -> To Version 6.0.0-alpha.1.21101.2 * Update dependencies from https://github.com/mono/linker build 20210203.1 Microsoft.NET.ILLink.Tasks From Version 6.0.0-alpha.1.21079.1 -> To Version 6.0.0-alpha.1.21103.1 * Add warnings to baseline Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: Mateo Torres Ruiz <matorre@microsoft.com> Co-authored-by: Marek Safar <marek.safar@gmail.com>
…ts dotnet/arcade (#47797) * Update dependencies from https://github.com/dotnet/runtime-assets build 20210202.1 System.ComponentModel.TypeConverter.TestData , System.Drawing.Common.TestData , System.IO.Compression.TestData , System.IO.Packaging.TestData , System.Net.TestData , System.Private.Runtime.UnicodeData , System.Runtime.TimeZoneData , System.Security.Cryptography.X509Certificates.TestData , System.Windows.Extensions.TestData From Version 5.0.0-beta.21062.1 -> To Version 5.0.0-beta.21102.1 * Update dependencies from https://github.com/dotnet/arcade build 20210201.7 Microsoft.DotNet.XUnitExtensions , Microsoft.DotNet.VersionTools.Tasks , Microsoft.DotNet.Build.Tasks.TargetFramework.Sdk , Microsoft.DotNet.Build.Tasks.Packaging , Microsoft.DotNet.Build.Tasks.Installers , Microsoft.DotNet.Build.Tasks.Feed , Microsoft.DotNet.Build.Tasks.Archives , Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.ApiCompat , Microsoft.DotNet.CodeAnalysis , Microsoft.DotNet.XUnitConsoleRunner , Microsoft.DotNet.GenFacades , Microsoft.DotNet.GenAPI , Microsoft.DotNet.RemoteExecutor , Microsoft.DotNet.Helix.Sdk , Microsoft.DotNet.SharedFramework.Sdk From Version 6.0.0-beta.21081.1 -> To Version 6.0.0-beta.21101.7 * Update dependencies from https://github.com/dotnet/xharness build 20210203.1 Microsoft.DotNet.XHarness.CLI , Microsoft.DotNet.XHarness.TestRunners.Xunit From Version 1.0.0-prerelease.21102.1 -> To Version 1.0.0-prerelease.21103.1 Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Removing Ahson as he is not on BCL team anymore
`unicode/uclean.h` was added in bdc8955 for `u_init()` when the PR was WIP: https://github.com/dotnet/runtime/pull/37971/commits By the time PR was merged, `u_init()` was removed, so this header is not required by any configuration.
* Fix dynamic pgo schema data copy
If the symbol is not found, close the library before returning false. Otherwise, the library is not stored anywhere and never cleaned up.
* Fix the c++ build. * Remove some unused prototypes.
…Core (#47031) * kill the process first, then remove the access and then remove the user this is to try to make TestUserCredentialsPropertiesOnWindows stable on Windows Server Core * is UnauthorizedAccessException thrown from finally swallowing a different exception (throw in the catch block)? * I was right, the first call to SetAccessControl was throwing What if we don't give the user rigts to execute it at all?
…#47847) * Remove the src/mono/netcore directory, move its contents to src/mono. * Fix docs and make targets. * Remove the netcore dir itself. * Fix samples.
We always need to run the profile data phase so that jit stress can inject random profile counts if it so chooses. Also, clean up a few dumping nits -- don't dump the profile query status until we get around to trying to incorporate counts; summarize schema records before asserting that we must have block counts, etc. Closes #47839
|
This PR is weird. I think you want to close it and delete the branch and just backport what you committed into master when your work is ready? |
Working towards #46178
This changes helps developers to set ServicePackage Msbuild property to enable building of the package. They no longer need to add the project name to libraries-packages file