When a VSIX project that contains MEF components is installed, how does visual studio find the MEF components? I know the regular way could be adding catalogs of dll directories that contains the MEF parts. How does Visual Studio know where to look to find the MEF in VSIX project?
Visual Studio Extensions (VSIX) usually contain a VS Package class, an extension.vsixmanifest file, and zero or more PKGDEF files that provided metadata and extension initialization information to the IDE.
VS is made aware of MEF components via a MefComponent registration in the extension.vsixmanifest file that indicates that a specific assembly should be scanned at MEF cache generation.
The simplest way to declare a MEF component in your extension is to right click on the project, select 'New Item', and add a Package to your project. This will provide the source.extension.vsixmanifest file to which you can add the MEF component registration. Double click this file, and add your registration in the 'Assets' tab of the VSIX manifest designer.
Related
I am working on Portable Class Library(PCL) and trying to achieve MEF in that. I used System.Composition from Nuget. When i build and package for vsix (Extension for Visual Studio) it doesn't package and place those dll's to extension folder
(C:\Users\UserName\AppData\Local\Microsoft\VisualStudio\14.0Exp\Extensions\ExtensionName\AppName\versionofYourApp). When i manually place those library in this folder it works fine. Can some one suggest a good solution to this problem. I am writing it for Roslyn Analyzers and creating a nuget package. Again i am facing the same issue, even if i am packaging those library together.
Set Copy Local to true in the VSIX's reference to the MEF DLLs.
I found a solution, thought of sharing. You are welcome to correct and suggest. For Vsix extension i added those library as an asset(VisualStudio.Assembly) from local.
And for packages, Assembly.Load("AssemblyName") was trying to load library from all possible locations like " C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\PrivateAssemblies" and many. So i placed it there and it was getting loaded. I know this is not the best solution. You are most welcome to suggest.
I have a Powershell Tools for Visual Studio 2015 project that is a script module. I would like to add a project reference to a .NET 4.5 class library that is also a project in the same solution. From a visual perspective the dependency is listed under the references tree in the powershell project but it has the warning overlay icon on it. When running the pester tests they error out with a type resolution error (Cannot find type [IHE.Cda.TrifoliaParser]: verify that the assembly containing this type is loaded). I cannot find any documentation which indicates whether what I am attempting is even possible. Thus my question is whether it is possible or if the references list is just a artifact of being in visual studio.
Solution Explorer View
The References are an artifact of VisualStudio. It would be possible to generate an Import-Module <PathToThe>.dll line on top of every script in your project, but that's very obtrusive, and not every script will need all the dependencies.
I have a solution in Visual Studio 2013 with more C# project files that have source code in common but are targeting for different platforms (.Net, WinRT, .Net Micro Framework and so on).
All the csproj files are under the same directory.
These projects use a Nuget package that is available for all the above platforms itself.
If I add this Nuget package for one of the project (ex. .Net), the package.config file is created and inside has reference to that target (ex. .Net). The package is downloaded in the packages folder.
If I try to add the same package but for a different target to another project in the solution, the UI tells me that the package is already installed. It's true because a package.config file is already there but I'd like to have the same package for a different target.
So my question is the following : how can I add the same Nuget package to all different projects but with different targets ?
Thanks,
Paolo
Unfortunately, I don't think NuGet supports your scenario.
NuGet expects the packages.config file to be in the same folder as the .csproj file. There should be a 1-to-1 relation between these files. You should create a separate folder for each project rather than keep all .csproj files in the same folder.
If you want to share code across multiple projects, the easiest way is to use the new Shared Project support in Visual Studio. Normally this only applies to Universal Projects, but there is an extension[1] that you can install that enables Shared Projects for all project types.
Simply create a new Shared Project. Add all you common code to it. Then in your platform specific projects, you can simply Add Shared Project Reference.
Since each project is now independent, NuGet will add the appropriate package.
Hope this helps. Good luck!
[1] Shared Project Reference Manager https://visualstudiogallery.msdn.microsoft.com/315c13a7-2787-4f57-bdf7-adae6ed54450
I have created a NuGet gallery in my company.
I want to create and publish a solution level NuGet package.
Everyone who will install the package will not get a dll but an entire project added to his/her visual studio solution.
Just like adding an existing project, the user will get a project with source code classes and everything is ready to use.
Just build it and use it.
I know it's possible, but couldn't find any documentation.
Anyone?
It is possible to add any files (not only .dll) and even directory structures to a NuGet package, so in theory you could store all files belonging to a project in a package and publish that. However, it is only possible to install NuGet packages into an existing project, meaning that you won't be able to add the packaged files as new project to any solution. In addition, the contained files will be put to the solution's packages folder, not to a solution or project folder.
As an alternative, consider creating a Template project instead of a NuGet package, as explained in How to: Create Project Templates and my blog post Creating template projects. This will result in a .vsix file that any developer can install as Visual Studio Add-In, the templated project will then appear in Visual Studio's File -> New -> Project... dialog as new project type and can be added to any solution.
Similar to your NuGet gallery, it is also possible to create a private Visual Studio Gallery to share such Add-Ins within, for example, a company, as explained in this MSDN article.
I understand how to build dll nuget package
I would like to build a JavaScript nuget package of my own. I would like to learn how jQuery nuget package being constructed/installed by nuget.
How do I know how jQuery (or similar nuget package) nuget package being constructed? Especially I would like to know how these *.js being copied/ installed to specific folder (scripts) of a ASP.net MVC project
Thanks
NuGet uses a convention-over-configuration approach. This is what makes it easy to inject some files (images, code, javascript, etc) into a specific folder of a target Visual Studio project.
You can simply open a .nupkg file with any zip-utility (e.g. 7zip) and extract the archive to see its contents.
A NuGet package can have 3 folders: lib, content & tools.
Anything in the content folder will be injected into the target project using the same relative path to the project root as to the content folder of the nuget package.
More info here: http://docs.nuget.org/docs/creating-packages/package-conventions
Also with respect to how jQuery or other similar Javascript libraries are packaged, here are some pointers.
The list of public jQuery/jQuery plugins that have been "NuGetified" can be see here http://nuget.org/packages?q=jquery The jQuery NuGet package page http://nuget.org/packages/jQuery has a note saying that it is maintained by the NuGet Community Packages project.
If you go to the CodePlex project at http://nugetpackages.codeplex.com/ and browse the source code, you'll find it contains a couple of sub projects. These are NuGet package projects for the respective open source (mainly Javascript) projects.
You will notice that they simply include the relevant pure Javascript packages, e.g. jquery-1.8.3.js, jquery-1.8.3.min.js, etc. in the Content/Scripts path.