We have a visual studio package (VS Package) that references a class library project (Project A). Project A in turn references another class library project (Project B).
So the dependency structure looks like this: VS Package > Project A > Project B
All projects exist inside the same solution and the dependencies have been set up as proper project references.
If I build the package in visual studio and look in the bin/Debug folder all necessary assemblies are there including Project B's. However when the package is deployed, only Project A's assemblies are present and Project B's are missing. How do I tell visual studio to include the indirect dependency of Project B in the package?
This MSDN document suggests that "By default in a multi-project solution, if a project that outputs to a VSIX package includes a reference to another project in the same solution, it includes the dependencies of that project."
However I am finding that this is simply not the case.
My question is very similar to this one except that I am having trouble with the main project assembly and not the localization satellite assemblies. The answer in this other post does not work for me because it seems to only work for satellite assemblies.
Is there some other Output Group that I can specify to direct the package to include indirect dependencies as well?
Thanks for looking.
The simplest thing to do in this particular case is reference Project B from the VSPackage project and set the "Reference Output Assembly" property to False to avoid introducing a compile-time dependency.
I had a similar problem: My VS Package project referenced another VS package project (~Project A) which in turn referenced a bunch of other projects (~Project B) containing the meat of our extension.
Inspired by this answer: VSIX package doesn't include localized resources of referenced assembly, I added 'BuiltProjectOutputGroup;BuiltProjectOutputGroupDependencies;GetCopyToOutputDirectoryItems;SatelliteDllsProjectOutputGroup' to the Output Groups Included in VSIX property of the reference from VS Package to Project A.
This had the effect of dropping all the dependency DLLs in the ...\Debug\ folder for my VS Project, but they still didn't get included in the VSIX.
Finally I went and added the BuiltProjectOutputGroup;BuiltProjectOutputGroupDependencies;GetCopyToOutputDirectoryItems;SatelliteDllsProjectOutputGroup flags to all the references from my Project A to each of my Project Bs - then they all got included in the VSIX.
(BTW this is with with Visual Studio 2013, but it doesn't seem to have change much since 2010)
Related
I'm trying to understand why removing a project reference prevents my build from downloading all the NuGet packages it needs. This is with Visual Studio 2019
Application A (.NET 5) holds a project reference to Assembly B.
Assembly B uses a NuGet package C.
When the build starts, NuGet Package C get downloaded automatically.
This is all vanilla expected, .NET stuff.
But then I realized that A does not actually use any B-specific types. B is a Prism Module that only loads dynamically if the user has a license for it and clicks a button. So A doesn't even always load "B".
So I removed A's project reference to B. I don't want some future developer to accidentally think they can start referring to types in B. (We don't ship all modules all the time). Technically now, there is no project in the solution that holds a reference to B. But it's still part of the build. I did set up the build dependencies so that B would still build before A but there's no longer a project reference..
Then I did a clean build. Visual Studio said it completed successfully. And I see Assembly B got built. But the build process did NOT retrieve NuGet package C (that B depends on). Testing has revealed it will not retrieve C unless application A actually holds a project reference to B.
Is there some way around this? If I'm building all assemblies, why would MSBuild not download all assemblies dependent NuGet packages. Is there some setting I can change to make it happen.
Answering my own question in case anyone else ever has this problem:
I asked this question of Microsoft. They said that this behavior is by design: If a DLL-generating assembly ("B") uses a NuGet package, then the only way that package will be downloaded at build time is if an assembly that generates an EXE has a project reference to B. Merely having a build dependency is not enough.
No explanation as to why. I still think the behavior should be different for reasons I mentioned in the question and comments above. They said it is a question for the .NET team and referred it to them. I finally got a reply that said, I can make this behavior happen by adding an attribute (named CopyLocalLockFileAssemblies) to my Assembly B's project file.
So I did. Added this:
<PropertyGroup>
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
</PropertyGroup>
And it worked. With this attribute set to true, an assembly that requires a NuGet package will get that assembly in the output folder regardless of whether or not anyone has a project reference to it.
(One could argue that this is a RTFM sort of question. But learning MSBuild and its ins-and-outs is one of many things I "eventually need to do" on my plate)
I have noticed many times that developers tend to reference assemblies directly by browsing to the .dll file under the .\packages folder (installed by another project) and adding that to project references instead of installing the nuget package on that project. In that case, even though it compiles, but the Nuget Package Manager does not know that the referenced assembly is from a package, and so updating the package solution-wide does not update those references in that project. If you are doing a Service Oriented architecture where each piece of feature in your application is a separate project in the solution, then you probably have hundred of projects, and managing those references would become a nightmare. Is there any way to prevent developers from referencing assemblies directly if they belong to a nuget package? For example is there any MSBuild task to verify all references to package assemblies require the package to be installed on the project?
If your team uses resharper, they have a plugin to help with this:
http://blog.jetbrains.com/dotnet/2012/11/20/add-packages-not-references-a-nuget-plugin-for-resharper/
I'm guessing the issue is caused by people using resharper without it, since by default VS won't know to include that DLL but Resharper will find it and reference it (and not update package config without the plugin)
Also get used having people using nuget at the solution level, not project level. That will force people to update all nuget packages across the solution, and not leave you with V 1.1.1.0 on Project A and v 1.1.2.0 on Project B.
I'm using visual studio 2010, and its a C++ solution with multiple projects. I have project A which has reference to project B(Properties->Common Properties->Framework and References). Project C references project A.
Now the build order is B->A->C. C now indirectly references B, is it required that we should manually add Project B as reference to project C?
I want to make sure that when project C is built project B should automatically be built if any changes were made to it and it is not rebuilt yet.
Building your Solution should always build Projects that have changes.
A circular dependency is created if you try to make B->A->C->B. You can have circular dependencies in VS but the build order must be managed manually. See this post.
If a Project references an assembly and not the Project that builds that assembly then VS does not build the dependent Project. If the Project references the Project that builds the dependent assembly then any changes to the dependent Project are built before the target Project. This is the default behavior in VS. That behavior can be changed or managed using the 'Build Dependency' dialog.
I have a big VS2008 solution containing >30 VS projects with legacy code. One of these projects (let's call it A) generates a header file, which is needed by a few other projects (for example B). When I go to "Project Dependencies" of the VS solution, I can check project A for project B's dependencies - but VS includes in the project B's linker command line options an additional argument for project A's lib ("A.lib"). Unfortunately, since project A does not create a lib file, this project B will never find one and cannot be built.
Is there a feasible solution for my problem?
Thanks in advance!
Cheers,
Chris
You should set Ignore Import Library in project A.
This option specifies that the (import) library generated by this configuration should not be imported into the dependent projects.
It is not possible to "Add reference" of managed project on native.
I have found here that this is possible via "Add item" - reference to dll. But in such case rebuild of dependent projects will not happen.
If I add dependency directly in project files via <ProjectReference> item group item, VS shows dependent project in References, but with Exclamation mark (!).
How to add reference of managed project on native one smoothly?
Thanks!
If you are trying to capture inter-project build dependencies at the solution level where those projects can't actually reference each other, you can set up explicit dependencies inside Visual Studio by right-clicking on the project in question and choosing "Project Dependencies...".
You can explicitly specify the dependencies here (but implicit dependencies will already be greyed out). Adding dependencies in this way will alter one or more ProjectDependencies sections in the solution (.sln) file so that building it from either devenv.exe or msbuild.exe will ensure correct build order.