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.
Related
I have an ASP.NET MVC 4 app developed in VS 2012. The app consists of a main project (MyProject), a unit-test project (MyProject.Tests), an Azure deployment project (MyProject.Azure), and a couple of general-purpose library projects.
When I right-click on either the solution or the main project and select Manage NuGet Packages, I see a bunch of Microsoft updates that have apparently become available in the last month or so. If I click on the Update All button then the updates are apparently installed without any obvious problems, but when I build the solution I get this error message TWICE:
warning : All projects referencing MyProject.csproj must install nuget package Microsoft.Bcl.Build
Ok, so I have two projects that reference MyProject: MyProject.Tests and MyProject.Azure. I can right-click MyProject.Tests, select ManageNuGet Packages, and add Microsoft.Bcl.Build. That gets rid of one of the two warnings. But VS does not give me an option to manage NuGet packages for the MyProject.Azure project.
How do I add the Microsoft.Bcl.Build package to the Azure deployment project?
EDIT:
Thanks to user swell, I now know that a Microsoft Connect issue for this problem has been opened here.
The answer provided by TheESJ is correct, however the wording wasn't clear to me. Since I cannot comment on the answer, I will provide more details here. Specifically, I was having this problem with an Azure project and the following workaround was required to make the warning go away:
When you double-click the warning in VisualStudio, you will be taken to the BclBuildValidateNugetPackageReferences target in the Microsoft.BclBuild.targets file. Above the actual target element, you should find a large comment block that talks about disabling the project reference checks. Since Azure projects cannot have any library references, it is impossible for those Azure projects to fulfill the requirements of this particular build target.
The solution? Disable reference checking from the Azure project since it is impossible to actually add a nuget package reference.
EXAMPLE
So, assume we have two projects: MyAzureProject.ccproj which references MyProject.csproj. Follow these steps:
Right-click on "MyAzureProject" in the Solution Explorer and select "Edit Project File."
Find the project reference to "MyProject." It should look something like:
<ProjectReference Include="..\MyProject\MyProject.csproj">
<Name>MyProject</Name>
<Project>{1d99490e-d140-4897-9890-238e673a5864}</Project>
...
</ProjectReference>
Add the following element inside of the ProjectReference element:
<Properties>SkipValidatePackageReferences=true</Properties>
Your project reference should now look like this:
<ProjectReference Include="..\MyProject\MyProject.csproj">
<Name>MyProject</Name>
<Project>{1d99490e-d140-4897-9890-238e673a5864}</Project>
...
<Properties>SkipValidatePackageReferences=true</Properties>
</ProjectReference>
Right-click on "MyAzureProject" in Solution Explorer and choose "Reload Project."
You should now be able to rebuild and the error should be gone.
If you double click the warning it gives you instructions for disabling the warning.
It is safe to disable for projectreferences from projects that don't yet support Nuget.
See below portion in bold copied from Microsoft.Bcl.Build.targets.
BclBuildValidateNugetPackageReferences
This target can be disabled for a project reference by setting SkipValidatePackageReferences=true for the reference:
<ProjectReference Include="..\pcl\pcl.csproj">
<Project>{664a9e98-fac7-4567-a046-0dde95fddb48}</Project>
<Name>pcl</Name>
<Properties>SkipValidatePackageReferences=true</Properties>
</ProjectReference>
I faced the same issue and was trying to update Microsoft.Bcl.Build.targets; which did not help.
After some investigation found that .csproj file of the Azure Service project must be modified to include <Properties>SkipValidatePackageReferences=true</Properties>.
This was not apparent from the answer of #TheESJ and so decided to post separate answer. Thanks to #TheESJ.
I encountered this issue a number of times, and the Properties method does indeed work, but when dealing with a Wix project, I had to do the following instead:
<AdditionalProperties>SkipValidatePackageReferences=true</AdditionalProperties>
When I used the Properties Xml node, I got a new error:
The OutputPath property is not set for project
'MyInstallerProject.csproj'. Please check to make sure that you
have specified a valid combination of Configuration and Platform for
this project. Configuration='Debug' Platform='x86'. This error may
also appear if some other project is trying to follow a
project-to-project reference to this project, this project has been
unloaded or is not included in the solution, and the referencing
project does not build using the same or an equivalent Configuration
or Platform.
After failing to resolve the issues with any of the above answers, I simply followed the instructions contained within the Microsoft.Bcl.Build.targets file (displayed after double clicking on the error in the build output window).
I unloaded my project (referencing Azure packages), encountering the error. Edited the project file and inserted the following...
<PropertyGroup>
<SkipValidatePackageReferences>true</SkipValidatePackageReferences>
</PropertyGroup>
...at the top of the project file before the first PropertyGroup.
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)
I have a simple solution in Visual Studio 2010 containing a few static libraries, a few DLLs, and an executable.
Some libraries depend one another (for example the DLL needs two static lib projects to be built before building the DLL itself), and it seems there are two way to achieve this:
1) If I right click on the solution I can select "Project dependencies..." and set the build order
2) I can right click on the DLL project and select Properties->Framework and References and then add a new reference.
What is the difference between #1 and #2? What is the better way to express a build dependency between two projects in Visual Studio 2010?
The only difference between a "Project Reference Definition" and a "Project Dependency Definition" is the metadata that defines the output assembly inclusion/exclusion into/from the main project link command.
In Visual Studio 2010-and-going-forward, Microsoft wants you to start using the "Framework and References" dialog, and stop using the "Project Dependencies" dialog (for now, the "Project Dependencies" dialog remains, will probably be removed in the future).
Here's a blog entry that talks about this, and other "Project settings changes with VS2010" by one of the Visual Studio developers:
https://devblogs.microsoft.com/cppblog/project-settings-changes-with-vs2010/
What is the best way to reference a project inside solution.
I added references via Add Reference --> Projects. However it links to either release DLL or Debug dll.
I want to have project itself in the reference, when we compile the projects, all the references projects must be compiled (through dependencies).
How to do this?
If you want to reference a project itself, and NOT a DLL/assembly (from the Browse tab in the Add Reference dialog), then you should add the project you want to reference to the Solution (Add... Existing Project). Once it's in the Solution, the Add Reference dialog will let you reference one project in the solution from another project in the solution (via the Projects tab in the Add Reference dialog).
When you unload a project in Visual Studio, any referencing projects get warning triangles on their reference to the unloaded project. I've written myself a macro to do clever stuff (detect add/remove of project and transform any references from-to file/project dependency), but I can't believe that I'm not missing something much simpler. How can the unload function be any use if I have to go around manually changing references (and it breaks the 'personal solutions/shared projects' team development paradigm).
(This question is related to answers to this question about structuring large solutions in Visual Studio - some answers mentioned having solutions with lots of projects, but 'unloading' unused projects to improve performance.)
For my projects, I create an assemblies folder which the projects automatically copy into from a set location to which other projects copy builds.
Post-build for referenced assembly's project:
if not exist "C:\builds\Project1" md "C:\builds\Project1\"
copy "$(TargetDir)$(TargetName).*" "C:\builds\Project1\"
Pre-build for referencing projects:
if exist "c:\builds\Project1\" copy "c:\builds\Project1*.*" "$(ProjectDir)assemblies"
The project file points to its assemblies subfolder for references so even if the source projects are unloaded from the solution, the last-built assemblies will be used without the performance problems of having the whole project in memory while developing.
What are the advantages of having projects in the same solution if you use file references?
If your app.exe uses utils.dll and you change the code for utils.dll, then if it's in the same solution VS will notice the dependency and recompile both. If it's not in the solution you'll have to jump out, recompile utils.dll seperately, then jump back in and recompile app.exe.
This becomes either more or less important depending on how many other dll's your exe is referencing, and how often they change (in team environments shared dll's change often in my experience).
There is also the side effect that if you have 100 projects in VS it will take a long time to process them all just to figure out if they need recompiling or not.
Unloading projects is meant to be a temporary action so you can edit the actual project file as XML (text). If you want to completely remove a project from your solution, you should use the "Remove" menu option, which will take care of removing any references to that project.
One advantage to using project references is that it allows you to easily debug through the code. It also automatically ensures that you are using the correct configuration build (ie, if you are building in "Debug" mode it will use the Debug version of the assembly). That being said, you loose some determinisim about which version/build of the dependent project you will pick up - project references mean you always use the latest.
Yes, for Visual Studio to determine build dependencies it must be able to see and build all of the projects which would mean project references.
I've just had a eureka moment reading through MSDN doc on structuring solutions and projects.
What I hadn't noticed is that in a multi-project solution, the context menu in the Solution Explorer proposes a Project Dependencies popup. Here you can define the project dependencies manually, if you haven't defined them by project references between projects.
See here (MSDN link, so will self destruct after a few weeks)