Age | Commit message (Collapse) | Author |
|
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.
|
|
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.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
The XS nunit add-in doesn't detect that UnitTests is a test project when
using new style package references. I'll revert when this is fixed in XS.
|
|
|
|
|
|
|
|
|
|
|