* Added the enable button on disabled plugins
* Added the disable function and button for installed plugins
* Changes based on the coderabbitai comments
* Removed markers and added the disable in the same if block as the unistall
* Hide the uninstall button when plugin is queued for enabling
* Removed the duplicate enale function
* Removed the disable button for installed plugins
* Removed the disableplugin functions as they are no longer needed
* Trigger CI pipeline after dotnet restore
* reverted the git ignore
Reported by @napoly
In an integration test for a plugin, attempt to resolve a type provided by that plugin using `BTCPayServerTester`.
For example:
```
tester.GetService<MoneroRPCProvider>();
```
The type should be resolved successfully.
The type fails to resolve.
During the test run, the dotnet runtime attempts to load `MoneroRPCProvider` in the default load context (`AssemblyLoadContext.Default`). It locates the plugin assembly in the test directory and loads it there.
In contrast, when BTCPay Server loads a plugin, it creates a dedicated plugin load context, and the plugin’s `MoneroRPCProvider` is loaded inside that context. This results in two distinct `MoneroRPCProvider` types: one in the default context and one in the plugin context.
This PR forces the plugin context, during integration tests, to load the types it resolves into the default assembly context rather than its own. This prevents duplicate type definitions.
As a side effect, behavior may differ slightly between running BTCPay Server normally and running tests, but this should be acceptable in most cases.
Relevant discussion: #6851
Reported by @napoly.
## Actual behavior
Two tests were created. When we would run the tests through the runner,
ASP.NET wouldn't find the registered view of the plugin.
## Expected behavior
The second test should works find, ASP.NET should properly find the
views of the plugin when there are more than one test in the same test
run.
## Cause
If we detected that a plugin assemly was already in the AppDomain, then
we were not loading the ApplicationParts of such assembly.
This wasn't the case for the first test run, but would be after.
The reason for initially doing this was that long time ago, we would
test plugins by referencing them from BTCPaySevrer project. But since
this is not how we are doing things anymore, I think it is safe to
remove this "Feature".
This feature was broken anyway since we started loading plugins in their
own context, but this wouldn't happen with the old way of referencing
plugins from BTCPayServer. (#6851)
* Fix: Plugin updates do not work
* Offer install on disabled plugins when different version
This will:
* Clear any previous pending actions of a plugin if you click uninstall
* Show the plugin version that was disabled
* Show an update button on disabled plugins instead of install
* if a plugin is scheduled to be installed/updated, it will show which version was scheduled to be updated. If a newer version if available than the scheduled one, it will show an option to switch to that
* Ensure disabled plugins don't get loaded
* View fixes
---------
Co-authored-by: d11n <mail@dennisreimann.de>
* Make NFC built int
* support checkout v2
* uninstall old plugin
* fix lnurl in unified checkout
* fix tests
* fix tests
* fix old checkout unified qr
* clean up and make nfc submission more sturdy
* support topup invoices for lnurlw
* fix test
* Payment URI fixes
* Fix LNURL exclusion cases
* UI updates
* Adapt test
---------
Co-authored-by: Dennis Reimann <mail@dennisreimann.de>
* More Options refactoring
Continues refactoring config classes to use the propert Options pattern where possible.
DataDirectories and DatabaseOptions are now configured the Options pattern and the BTCPayOptions is now moved alongside the other config setup
* Move COnfigure logic for Options to the Startup
This allows plugins to create custom dbcontexts, which would be namespaced in the scheme with a prefix. Migrations are supported too and the table would be prefixed too
* Plugins: Load plugins by order, aesthetic plugin dependency system
Introduces plugins loading in order of installation, BTCPay itself shows up as a system plugin, and that plugins can define other plugins as dependencies.
* use a proper type for plugin dependencies
* rebase fixes
* message when cannot install
* BTCPay Extensions Part 2
This PR cleans up the extension system a bit in that:
* It renames the test extension to a more uniform name
* Allows yo uto have system extensions, which are extensions but bundled by default with the release (and cannot be removed)
* Adds a tool to help you generate an extension package from a csproj
* Refactors the UI extension points to a view component
* Moves some more interfaces to the Abstractions csproj
* Rename to plugins
