| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Fixes https://dev.azure.com/devdiv/DevDiv/_workitems/edit/738212
|
|
Fixes #81
|
|
|
|
|
|
|
|
The previous fails when initializing the engine and there is no add-in
cache created. The enabled status consistency check is now done
after updating the db, and always using the registry's current domain.
|
|
When initializing an add-in dabatase ensure that all add-ins have all
their dependencies enabled. The database takes care to keep the
enabled status consistent at run-time (so if an add-in is disabled,
all dependent add-ins will also be disabled). However, that status
may already be inconsistent when loading the database, and that
may cause add-in loading issues. This may happen for example if
add-in A is disabled, and then an add-in B that depends on A is
installed externally, outside of the control of the db. With the
changes of this commit, when the db is initialized it will detect
that B depends on a disabled add-in and it will be disabled too.
Fixes VSTS #952473
|
|
Mono.Addins.ExtensionNode.get_Addin()
https://devdiv.visualstudio.com/DevDiv/_workitems/edit/935147
node.AddIn crashed and caused a fatal exception. That's now fixed and the error is reported.
|
|
|
|
Co-Authored-By: mikkeljohnsen <mikkel@xmedicus.com>
|
|
Co-Authored-By: mikkeljohnsen <mikkel@xmedicus.com>
|
|
and overriding the AppDomain.AssemblyResolve
This makes it possible to add additional search paths for the dependency check.
MONO_ADDIN_ADDITIONAL_PATH = "C:\Program Files\Framework\bin"
Will make the Addin loader look for Assemblies in "C:\Program Files\Framework\bin" first and if a match is found use that.
It will fallback to the normal internal check if no match found.
|
|
|
|
it will target 4.6.1, rather than 4.5.
This should fix a few binding redirects issues we have when building MD
|
|
When translating strings defined in an addin.xml file the addin
and its dependencies will be loaded. If conditions or extension
objects used this will result in addin assemblies being loaded.
If the addin does not have a localizer then the AddinEngine's
default localizer will be used and the addin does not need to
be loaded just to translate the string.
|
|
This is fired when the addin assemblies are loaded.
|
|
|
|
This will avoid some problems when downgrading from a monodevelop release
that bundles add-in scan data files to a release that doesn't. This is not
a real fix, just a temporary workaround.
|
|
|
|
|
|
Fix https://github.com/mono/mono-addins/issues/105
|
|
When using pre-generated add-in scan files, sometimes
updating the add-in db may cause a crash. That's because
a post-update process tries to refresh the domain of each add-in
and it is done by getting the domain of the folder that contains
the add-in. When using scan data files, there is only folder info
for the root directory, not for each add-in directory, so the domain
query fails.
The solution is to not try to refresh the domain. A domain change of
an add-in at run-time is an unlikely scenario that in general is not
properly supported, and it requires a restart.
|
|
Add a unit-test that writes and reads FileDatabase on Windows with different casing. Ensure case is normalized on Windows.
Add IVT to tests to expose internal APIs to tests.
|
|
Always serialize AddinScanFolderInfo.IgnorePaths, otherwise
it will run over the MD5 field when looking for it.
|
|
Try to serialize the AddinFileSystemExtension instance to remote
process, so that it is used for the real scan.
|
|
|
|
If the same addin with same version exists in the app folder and in the
user's addins folder, always load the one in the user's folder.
This will make it easier to test add-ins running on apps that bundle
the same version of the add-in.
|
|
and moved VS Marketplace to MonoDevelop
In processes had to make many classes and methods public to be accessable from MonoDevelop
|
|
|
|
|
|
|
|
Refactored the code to allow generating scan data files
independently from the add-in database update process.
The new AddinFolderVisitor class can be used to visit
all the add-in folders. Split the functionality previously
in AddinScanner in two classes. AddinRegistryUpdater is
now in charge of locating the addins. AddinScanner now
only implements the actual add-in scanning code, and the
logic to setup a custom assembly resolver has moved there.
|
|
|
|
[Database] Cache the dependency tree in AddinDependsOn
|
|
[FileDatabase] Optimize addin scanning
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Every time we load an extension point, we sort the data by the addin
dependency tree.
In the case of 100 extensions, we end up doing a linear search with
every addin when inserting into the sorted list.
The old code's limitation was that we had to create an addin dependency
tree on the spot for every addin with every addin.
That means we'd traverse the whole tree and construct it on every iteration,
for every check.
That potentially rounds up to O(N_DEPS) * O(N_EXTENSIONS^2).
This code makes the tree construction on demand, so the checking where it fits
is an O(1) for constructed cache, and O(N_DEPS) for non-constructed.
We transitively propagate deps of an addin to the parent, for hitting O(1)
in all cases.
The reason we now put the Name instead of FullId when doing recursive search is because,
for example, an addin written with AddinMaker will depend on MD.Core,7.0.
If 7.5 is installed, this would return false because we don't have an exact
match in the cache.
Making the HashSet use a custom comparer or getting the addin parts from
the addin id would be allocation heavy, so resort to discarding the version
when adding the list of addins (as the dependency code discards the version
anyway by doing in-exact matches)
Fixes #95. This reduces an UI hang that takes 1.70s when loading the project model extensions
in VSMac, and probably a lot more places are now faster because of this.
|
|
Eliminates 863ms out of 2.22s spent by ExtensionContext.GetExtensionNodes in VSMac
|
|
The format of the addin cache data is something like below:
Users_therzok_Work_md_monodevelop_main_build_AddIns_MonoDevelop.AzureFunctions_azure-functions-cli-66a932fb_nb_abf27ece.data
That means that the code which is removed was looking for something that would match:
<Full_Path>_sha*.data
Only 1 item matches that, and if the direct query did not exist, it means scanning
the whole folder for another file which matches the pattern is useless.
Reduces AddinDatabase.Update for full VSMac from 1.95s to 0.72s, that's 1.23 spent
just doing IO via Directory.GetFiles.
|
|
Added a new command and api that can be used to generate a file next to
each add-in file that contains the result of the scan. The next time the
add-in needs to be scanned, the scanner will load the data from the data
file instead of scanning again the add-in.
|
|
The VSMac 2017-08 branch build breaks with mono 5.6.0.x:
Using "ReportAssetsLogMessages" task from assembly "/usr/local/share/dotnet/sdk/2.0.0/Sdks/Microsoft.NET.Sdk/build/../tools/net46/Microsoft.NET.Build.Tasks.dll".
Task "ReportAssetsLogMessages"
/usr/local/share/dotnet/sdk/2.0.0/Sdks/Microsoft.NET.Sdk/build/Microsoft.PackageDependencyResolution.targets(323,5): error MSB4018: The "ReportAssetsLogMessages" task failed unexpectedly. [/Users/ludovic/Xamarin/monodevelop/main/external/RefactoringEssentials/RefactoringEssentials.2017/RefactoringEssentials.csproj]
/usr/local/share/dotnet/sdk/2.0.0/Sdks/Microsoft.NET.Sdk/build/Microsoft.PackageDependencyResolution.targets(323,5): error MSB4018: System.TypeLoadException: Could not resolve type with token 0100005b (from typeref, class/assembly NuGet.ProjectModel.IAssetsLogMessage, NuGet.ProjectModel, Version=4.3.0.5, Culture=neutral, PublicKeyToken=31bf3856ad364e35) [/Users/ludovic/Xamarin/monodevelop/main/external/RefactoringEssentials/RefactoringEssentials.2017/RefactoringEssentials.csproj]
/usr/local/share/dotnet/sdk/2.0.0/Sdks/Microsoft.NET.Sdk/build/Microsoft.PackageDependencyResolution.targets(323,5): error MSB4018: at Microsoft.NET.Build.Tasks.TaskBase.Execute () [0x00000] in <01420900fd004c128de2d2ee31bad624>:0 [/Users/ludovic/Xamarin/monodevelop/main/external/RefactoringEssentials/RefactoringEssentials.2017/RefactoringEssentials.csproj]
/usr/local/share/dotnet/sdk/2.0.0/Sdks/Microsoft.NET.Sdk/build/Microsoft.PackageDependencyResolution.targets(323,5): error MSB4018: at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute () [0x00023] in <765502eb2f884ce79731edeb4b0517fb>:0 [/Users/ludovic/Xamarin/monodevelop/main/external/RefactoringEssentials/RefactoringEssentials.2017/RefactoringEssentials.csproj]
/usr/local/share/dotnet/sdk/2.0.0/Sdks/Microsoft.NET.Sdk/build/Microsoft.PackageDependencyResolution.targets(323,5): error MSB4018: at Microsoft.Build.BackEnd.TaskBuilder+<ExecuteInstantiatedTask>d__26.MoveNext () [0x0022d] in <765502eb2f884ce79731edeb4b0517fb>:0 [/Users/ludovic/Xamarin/monodevelop/main/external/RefactoringEssentials/RefactoringEssentials.2017/RefactoringEssentials.csproj]
The missing token token 0100005b (from typeref, class/assembly NuGet.ProjectModel.IAssetsLogMessage, NuGet.ProjectModel, Version=4.3.0.5)
is referenced from the `Microsoft.NET.Build.Tasks.dll`. The
`NuGet.ProjectModel.dll` next to the tasks assembly has the type
available. But looking at assembly loader logs, it turns out that the
assembly is actually being loaded via a raw byte[] instead of from the
file.
More digging reveals that this is being done by
`Costura.AssemblyLoader`[1] which was loading the assembly from embedded
resources in `NuGet.Build.Packaging.Tasks.dll` assembly:
1e70e0: costura.nuget.projectmodel.dll.zip (size 55791)
And this seems to be out of sync with the nuget assemblies bundled with
the `Microsoft.NET.Build.Tasks.dll`.
`NuGet.Build.Packaging.Tasks`'s `ReadLegacyDependencies` targets gets
triggered because `Mono.Addins.csproj` has `PackOnBuild=true` for
Release builds. Hence, the issue is never seen in debug builds.
The `Costura` change was reverted in the nuget package upstream[2] but
that was committed after `v0.1.276`, which is the version being used currently.
So, we bump to latest version of the package - `v0.2.0`.
--
1. https://github.com/Fody/Costura
2. https://github.com/NuGet/NuGet.Build.Packaging/commit/7838a0a95fb8ce5c9db7b7d4d2bfe62f38b4eddb
|
|
|
|
The reflector now takes into account that some assemblies only have to
be loaded if they reference Mono.Addins. For example, when looking for
a subclass of Mono.Addins.ExtensionNode, only assemblies that have a
Mono.Addins reference can define such class.
This optimization can be applied in several cases and reduces the
number of assemblies that are loaded.
An UnloadAssembly method has also been added, and it is used to unload
potential add-in assemblies when there is an error while scanning.
|
