| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Fix nested event dispatch issue
|
|
|
|
Event handler invocations are done through a dispatch queue, to ensure that
they are dispatched in the right order in multi-threading scenarios.
The dispatch queue is also used when invoking a handler as a result of
an event subscription. For example, when calling AddExtensionNodeHandler,
the handler should be immediately invoked for all existing nodes in the provided
extension path. However, if AddExtensionNodeHandler was invoked within an
event handler, those invocations would be queued and not executed immediately
as the caller would expect.
The solution is to do the handler invocation for existing nodes like it used
to be, not through the queue. However, the actual event subscription still
needs to be done through the queue, to avoid receiving unnecessary events.
There is a more complete explanation in the code.
|
|
|
|
Moved notification queue from ExtensionContext to to add-in engine. The problem
was that when a node is removed, it is not bound to a context anymore, but it
may still need to make use of the event queue.
|
|
|
|
When removing many nodes in a transaction it may happen that a parent
is removed before its children, since the list of nodes to remove is
in a hashset, so there is no defined order. Added a null check to avoid
a crash when that happens.
|
|
Make mono.addins thread safe
|
|
By default Microsoft.Net.Test.Sdk bring in Newtonsoft 9.0.1, but that has a vulnerbility to fix, so explicitly references the updated Newtonsoft with the fix, 13.0.1
|
|
|
|
In some cases when add-ins are downgraded the add-in database may be left in
an invalid status. This happened because the add-in scanner did not properly
compare the versions of the old and the new add-in, so it did not uninstall
the old add-in when versions were different. This resulted on the old and
new descriptions of the add-in to be kept in the database, and it might
generate add-in dependency errors.
This also happened when upgrading, but since the engine always loads
add-ins with the highest version it doesn't matter if there is one with
lower version also registered.
The solution is to cache information about the old add-in version, and when
comparing ids, use that information.
Added unit tests.
|
|
|
|
|
|
Make sure the test repo dir is cleaned for every test run.
|
|
|
|
Split the context transaction class in two classes, one for extension context and one
for add-in engine (which is a context by itself). In this was there is no danger of
providing a context transaction to an add-in engine method and expect it to work.
Added method for stating an engine transaction from a context transaction.
Fixes tests.
|
|
Reduce the number of transactions being created by propagating them.
Created a transaction when the engine is initialized, so that the initial
loading of add-in roots is all done using a single transaction.
Fixed unit tests.
|
|
And fixed threading issue.
|
|
|
|
Remove the concept of TreeNodeBuilder, it was getting
too complex. An easier solution is to add a transaction
mode to TreeNode, which when enabled handles children
in a list builder, and which is committed when ending
the context transaction.
Fixed several bugs.
|
|
|
|
|
|
Bring back SetupDomain to be used only when targeting .net framework.
When target is .net core, use the local scanner, but for the
use of the cecil loader.
|
|
Before the UnitTests was using a ProjectReference without
ReferenceOutputAssembly set to false. This would prevent
the project building if the SetupProcess project was
targeting an incompatible target framework, such as .NET
Core. Now ReferenceOutputAssembly is set to false on the
project reference and the executable files are copied in
a custom msbuild target after the build finishes. Also
have to add SkipGetTargetFrameworkProperties to true
for the project reference to workaround an MSBuild bug
where the build fails with UnitTests referencing a
.NET Core 3.1 SetupProcess project even though it does
not compile against its assemblies.
|
|
Fix warnings about assemblies not being strong named.
The internals visible to information was missing the
public key.
|
|
Set AppendTargetFrameworkToOutputPath to false in all projects
so everything builds into the same bin directory.
|
|
Some tests were checking the assembly version of the test addins
were 0.0.0.0 however the default for SDK style projects seems to be
1.0.0.0. Changed the test addin projects to use the 0.0.0.0 version.
|
|
Test addins now built into the lib directory instead of a subdirectory
based on the target framework.
UnitTests project now built without appending its target framework
to the build directory.
This fixes some tests that were relying on the location of the
test addins being in the lib directory. Still 38 tests failing.
|
|
The tests do not run tests with the external SetupProcess currently
but having the UnitTests copy this allows this to be tested locally
by changing the AddinDatabase.GetSetupHandler method.
|
|
MultiAssemblyAddin project has two projects in its directory
and the SDK style file globs were including .cs files from
these projects causing compilation errors. These project
directories are now excluded from the project.
|
|
|
|
.NETStandard2.0
|
|
|
|
Don't look up CurrentAddin by assemblies loaded.
CurrentAddin - at least in tests - will use something like UnitTests.dll
which is not always loaded via the non-expensive check.
Use AssemblyName.GetName instead of adding new API
|
|
|
|
|
|
|
|
|
|
localizer is supplied
This should avoid probing for a built-in localizer when a custom one is supplied.
|
|
|
|
|
|
|
|
Fixed several issues that caused unit tests to always fail when running from
inside VS Mac.
|
|
Fixes #81
|
|
|
|
it will target 4.6.1, rather than 4.5.
This should fix a few binding redirects issues we have when building MD
|
|
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.
|
