I'm writing a Visual Studio extension package (VSIX). It uses MEF, as is usual to plug into VS.
Instead of creating another container, is there a way for me to reuse the MEF container, exporting and importing my own internal classes? I've tried [Export(IMyInternalThing)] and [Import] IMyInternalThing thing; but the import is never satisfied. And this is inside a class that IS being used by VS and MEF to fulfill one of its own imports successfully.
So why doesn't MEF fulfill my import?
Related
I am working on a nunit engine extension which will be shipped as a nuget package.
Following the advises in How to implement NUnit's NUnit.Engine.ITestEventListener i was able to write the extension.
This solution is working as long as the project which contains the extension (the .cs file as well as the .addins file) is being imported to the target project which will perform the nunit tests.
As soon as I create a nuget package (following Quickstart: Create and publish a NuGet package using Visual Studio (.NET Standard, Windows only)) from the extension project and install this package to a test project, the extension doesn't work anymore.
I assume there is a problem with providing the .addins file within the nuget package so that the nunit engine in the target project can find the extension.
I already tried to ship the .addins file within the nuget package by adding the following lines to the .csproj file of the extension project.
<ItemGroup>
<Content Include="file.addins">
<Pack>true</Pack>
</Content>
</ItemGroup>
If I add the .addins file to the target project by hand, the engine extension starts working.
How can a nunit engine extension be shipped as a nuget package without any adjustments by hand?
Im using NUnit(3.13.2).
Im quite new to nunit, nuget and writing questions on stack overflow. So if I'm missing something obvious here, I'm sorry.
This is one of those areas where I wish things were less complicated, unfortunately. Since extensions are found through a relative path from the NUnit engine to the package content, it depends on where both the engine and runner are located and where the package is located on your machine.
Here are some initial guidelines...
How to structure the package itself... your extension assembly itself should be in the tools directory. If there are other assemblies with it, which it references, it's best to also include a .addins file in the same directory, which lists that assembly on a single line. That way, the NUnit engine will save time by only examining the extension assembly.
A NuGet extension package will automatically be found by the engine if the runner has been installed as a nuget package as well. This works no matter how the packages are installed on your machine, i.e. using packages.config or in a nuget cache, provided both packages were installed the same way. (That proviso is a real gotcha and it may be that a future version of the engine needs to actually understand nuget.) See the addins file provided with the the NUnit 3 console runner as an example of why this works.
The same thing is true if both the runner and the extension are installed as chocolatey packages, because they are both in the chocolatey cache. If you do provide one (which I recomend) it has to be a "native" package - one that includes the actual binaries. A chocolatey package that merely invokes the nuget package will not work. See the source for any of the NUnit-provided extensions for an example of how this this is done.
If the executing copy of the engine (usually in the same directory as the runner) is anywhere else, there is no automatic way for the extension to be found. This includes the case where you are building a runner yourself and want the extension to be available while you are developing. In that case, you need to fully understand how the engine finds extensions (see the docs) and manually create an addins file (next to any that was distributed with the engine) containing the proper relative path.
This is especially complicated if you are developing an extension for general release. Then you have to deal with various runners installed in different ways by different people. OTOH, if you are doing this for internal use in your company, you may only need to deal with one of them. If you add more specifics about your goal to the question, I'll edit this with some more specific suggestions.
I am developing an scripting environment for EMF and need to import the model plugin so that my script is able to use classes generated by the model, but in order to do that I need to explicitly add the plugin to my imports.
Can I do that automatically? Like adding all workspace plugins to my imports at runtime?
You can use DynamicImport-Package: * attribute in the bundle manifest to make all exported packages visible.
Note that packages imported via DynamicImport-Package are resolved every time a class from the package is needed. Consider selective dynamic import DynamicImport-Package: *;dynamic=mymodel or buddy policy as better alternatives.
Is there a way, in Scala and SBT, to automatically generate META-INF/services/* resource files for later use by java.util.ServiceLoader by annotating classes, like Google Auto Service does for Java projects?
i.e.
package foo.bar
import my.exported.ServiceInterface
#AutoService[ServiceInterface]
class MyService extends ServiceInterface{
// …
}
to automatically generate the file META-INF/services/my.exported.ServiceInterface in the resources folder. The file will contain:
foo.bar.MyService
(I don't think I can use Google Auto Service directly, as it doesn't work with Scala classes -- see this comment on a realm-java github issue.)
Please consider using https://github.com/nyavro/spi-plugin.
The approach used in this plugin differs from using annotations - it uses whole packages as a source of interfaces and applies to packages of interface implementations.
I have a common DataAccess Class Library Project. This project needs to be Referenced in multiple Visual Studio Solution.
Currently we are Referencing this DA Library via Folder created in each project called binary.
so whenever there is a change in DataAccess Library project, we have Manually update all the projects that are Referencing this DAL.
I was thinking about creating Single Solution, which will have All the Projects
including DAL & all other Projects that are Referencing it and change the Reference to PRoject Reference DAL from other Projects, instead of File Reference from Binary folder.
Is there any other Better Solution around sharing this DAL ?
The answer is Nuget.
You should package you dal output as a nuget package and push it to a nuget server.a nuget server can be a network share our an application like ProGet.
Preferably you have an automated build do there package and push. That makes it easy.
Then each of your other solutions can take a dependency on that package. When you update it in the Nuget server each of the solutions will notify of a new version that can be used.
is it possible to include an EntryPoint inside the GWT project's test folder?
if so, how to refer this EntryPoint in the [module-name].gwt.xml file?
my purpose:
to build a JavaScript library wrapper as a single GWT module which separates the emulation environment (the EntryPoint class and its containers, panels etc.) into the test folder, while leaving the src folder clean from EntryPoint classes or containers and panels used for emulation.
that way, i can pack only the src folder into a jar, to be used as a clean GWT module.
currently i am building separate projects for the module and for the emulation - the emulation project reference and inherits the module, and the module is strictly clean (holds the public JS sources, but no EntryPoint or HTML / CSS files).
note:
already tried to add the test folder to the classpath or include it as a source in the [module-name].gwt.xml.
The test folder usually execute java code and the gwt compiler doesn't compile code from there. What it sounds like you may need is to put your wrapper gwt in a standalone module that doesn't have an entry point. Then you need module with an entry point just to bootstrap the library module you have created to test the wrappers in the browsers. It will be easiest if you create the test/bootstrap module as the project, then create a separate module for the wrapper stuff. Be sure to include an for the wrapper module in the project module so it can link in the wrapper code.