Here's my question:
I have Project A which is referenced in Project B, but the problem is I also need to reference Project B in Project A. However, every time I try to do it there is an error which states that it cannot reference Project B to Project A because it will cause a circular dependency.
So can anyone suggest a workaround for my problem?
This is generally a bad idea. If there are some common things that might need to be shared by both assemblies, move it to a third assembly and have both projects reference that instead.
Related
I'm currently creating a huge database solution with over 40 projects and tons of references.
It's a very common situation that project A references project B, then project B references project C and so on like this:
A->B->C->D
When I'm trying to build project D it's all working correctly. Same for project C, it resolves reference to D and builds successfully.
When I try to build project B I get an error like this:
The reference to external elements from the source named D.dacpac' could not be resolved, because no such source is loaded.
I'm sure that all references are set up and nothing is missing. My dacpacs are stored for each project in bin/Debug folder.
Please help me with some hints or ideas on how to continue my investigation.
Even do I've answered in the comments already, it might be helpful for other with similar problem.
The solution is: you need to add reference to parent project of all other dacpacs. So in your case project B should have reference for both C and D projects.
Another possible option would be to tick the "Reference to external elements problem with nested database references" checkbox when you add reference to C project, but that's not always work.
I am migrating an old style MsBuild csproj project to using PackageReference format and have run into a problem with transitive dependencies.
Consider the following
Project A reference NuGet package B and C, each containing one single assembly using PackageReference.
On Build Project A uses IL merge to incorporate B as public symbols in the A assembly and C as internalized symbols.
Project D have a project reference to A.
The transitive dependencies case D to reference A, B and C.
When building D, compile errors of the type
error CS0433: The type 'X' exists in both 'A' and 'B'
occur.
Is there any way to force D to not add an explicit reference to B or C in the scenario above?
Disable transitive PackageReference dependency for a specific MsBuild project
If I understand you correct, you can try to use property <PrivateAssets>all</PrivateAssets>or PrivateAssets="all" for the PackageReference. If you have a package that's marked with private assets it merely prevents it from flowing to parent project or getting packed.
<PackageReference Include="B" Version="1.0.0" PrivateAssets="all">
<PackageReference Include="C" Version="1.0.0" PrivateAssets="all">
You can check the document Controlling dependency assets and this thread for some details.
Hope this helps.
I ended up using a workaround to move the transitive dependency to an alias to get around the compiler error.
<Target Name="ChangeAliasesOfBNameAssemblies" BeforeTargets="FindReferenceAssembliesForReferences;ResolveReferences">
<ItemGroup>
<ReferencePath Condition="'%(FileName)' == 'B'">
<Aliases>nonmerged</Aliases>
</ReferencePath>
</ItemGroup>
</Target>
I tried to use private assets but couldn't get the compiler error to go away in that way.
I was looking for this too and this answer kept popping up in google searches, but it didn't have the solution I know off (but can never remember), so I'll add my answer for future reference.
PrivateAssets can be used to hide many things, but hiding all is a bad move imo. You want some assets to move transitively, for example, for your app to run after a dotnet publish, you'll need the assemblies you need, at runtime. Hiding all assets means that when publishing, you may miss a few critical things - similar to deleting some files from the output.
From reading MS docs on the subject, I think what I want to hide, in order to not transitively be able to compile up against an assembly (but still have it at runtime), is compile. So I'll set my PrivateAssets to contentfiles;analyzers;build;compile. This should mean that if MyLibraryB depends on NugetPackageA - then MyAppC depending on MyLibraryB will be able to run and publish correctly, without being able to use any classes or code from NugetPackageA.
Note: This of course means that MyLibraryB must not expose any public API that uses types found in NugetPackageA. The consumer won't be able to use those public API's, at least not without themselves also referencing NugetPackageA.
We've got a visualstudio solution with all our code in it and it's completely seperated from our unity project.
When we build our code into a dll from within visualstudio, the dll is copied over to the unity project plugins folder, so we can use the classes from it in our unity project.
This all works fine, but the problem is when we rename a class in our visual studio solution, rebuild the dll and go back to the unity project, the reference to the renamed class is lost in our scene and/or prefabs...
I looked into the scene & prefab files and noticed the references to the classes in the dll are defined as follows:
m_Script: {fileID: 698634159, guid: aa20b9c3579870b40bb96d13672546a3, type: 3}
I read on the forums that the fileID is generated based on the namespace & name of the class file, so logically when the class is renamed, this fileID changes and unity does not know it needs to reference the renamed class.
Is there a way to define a hard references of some kind, so the reference does not get lost when renaming a class? Or any other suggestions to keep references from getting lost.
I've also tried including a meta file with a guid in the dll, but unity does not seem to take this meta file into account, as it always uses the guid of the dll together with the generated fileId.
Unity can't automagickaly find out you have renamed some class inside the DLL. That's true for any form of project : if you depend on some DLL, and classes changes in the DLL, there is no indication of rename.
The best way to link them is adding your Unity project in the solution, and place a dependance between Unity project and the another. Then maybe the refactor tool will suggest you the rename in the Unity project.
Here is a really good tool to find and replace missing scripts, which i assume is the error you are getting.
http://daikonforge.com/forums/resources/fix-missing-scripts.3/
It comes with the source code once you unpack the Unity3d Package, so you can customize it to your needs.
I just banged my head for a while and figured out a solution, but I want to make sure that I'm doing things right and that I actually know what I'm doing (I'm pretty sure I never know what I'm doing :)
I have two projects that I've been working on, each offering different functionality. I want one project (A) to be able to use the functionality of the other (B). I tried going about it by creating a workspace and putting both projects into it, but I couldn't "see" project B's files from project A (autocomplete after #import did work, but it gave a compiler error). So I tried adding it as a "sub-project" and found the same. I figured this would be easy, but guess not.
What I ended up doing was creating a new project (C) as a "Cocoa Touch Static Library" project, and put my files from Project B into it. I built it.
I then went back to project A and added project C into it as a sub-project.
Then I added the path on the filesystem of project C into the User Header Search Paths setting under Build Settings of project A.
Then I added the .a file from Project C into the Link Binary with Libraries section of Project A.
Then it worked.
But honestly I have no idea what the meaning of a static library is.
Is all this necessary? Or is there an easier way to just integrate two projects (without me having to copy the files from one project to another)?
Thanks in advance!
Jon
You were on the right track with workspaces. What I do is have three projects in the workspace. One with no targets just to hold the generic classes. A second for my iOS target Project. And a third for mac. Keep the original files in the one with no target, then drag the files to the other two projects that creates references, so when you edit one it changes all three.
I'm trying to use code contracts for some libraries I have. My library A has a reference to ThirdParty library B. Library C references A, and never uses B nor does it use the bits of A that use B. The rewriter fails though trying to find library B. The reference assembly for A exists, I was hoping that the rewriter would be just happy with that.
Any ideas on how I can build this, short of moving the bits in A that rely on B out into its own assembly?
EDIT: To answer a question, yes, there are public types in A which expose types in B. I was hoping those the analysis would end at the library A, and that it would treat B as if there was no reference assembly at all (ie, ignore it).
It seems that there is no way around this. In some regards I think its good as it helps you see where your third party dependencies are leaking.