I have 3 PCL projects in the same solution.
Robin.Models
Robin.Services
Robin
I added the reference of Robin.Models project in the Robin.Services
Both the Robin.Models and Robin.Services projects were build successfully.
Now I add the Robin.Models project reference to the Robin project.
In the Robin project if I am adding any one of the Projects Models/Services then the the corresponding objects were resolved fine.
If I add only one reference Models then also it is working fine.
If I add the reference of Services also then all the classes/objects in the Models project are not getting resolved.
Even the using Robin.Models statement turns red after adding the Services project.
Any idea what is the issue.
Related
My project does not add reference to another in the same solution.
I created a project for a website and and abstracted all the parts of the program into .Net Class Libraries (My models in a different class library, Interfaces in a different class library, business logic in a different class library). I referenced all the projects correctly and I also tried creating something I call EntityRepository which I initially kept the DbContext inside. But due to the reason that I wanted to use Microsofts' implementation of Identity and then scaffold the logic out, I could not find the DbContext from the other project which is required when scaffolding so I had to exclude that project out of the solution. Normally when you create a project and select Single user authentication, .Net core adds an initial DbContext into the project. So when scaffolding the implementation of AspNetCore Identity into my project, i have to choose the DbContext. Because of that, my business logic has broken into two sides. The other logic is inside another project in the same solution, the Identity and authentication is inside the startup project which is the web application. When I tried calling the services which implement the business logic from the other project into the web project, it could not add reference to the services project. I now added reference manually. After that I now saw an error written
Detail Error:
Severity Code Description Project File Line Suppression State
Error NU1108 Cycle detected.
CBTSoftware.Web.Host -> CBTSoftware.Services -> CBTSoftware.Web.Host. CBTSoftware.Web.Host C:\Users\Tavershima\source\repos\CBTSoftware\CBTSoftware.Web.Host\CBTSoftware.Web.Host.csproj 1```
How can I resolve this?
Fist I want to show gratitude to those who answered above because they put on the right track to solving this issue. In my case the issue was caused by untrack files causing NU1108 and was resolved by running git clean -fxd
*git clean documentation
I know that this is old but I'd like to add here as well.
I had the same situation as Sebastian Widz answer but what really worked for me was opening the Properties of the problematic project.
This reloaded the project files/dependencies and fixed the "Cycle Detected" issue.
In my case the problem had nothing to do with actual dependencies.
One day I opened a solution (which was fine the day before) and could not compile it. NU1108 Cycle detected error was reported in error log for several projects.
Solution:
Examine all projects in the solution, check the solution content.
If for some projects you see wrong content like if the project had files attached from a different project, expand its nodes and wait a bit, VS should refresh the nodes after a while
You may also try to Clean Solution and Reload each project.
Consider making a project to contain your EntityRepository, like CBTSoftware.Data, and adding a reference to it from your services project:
CBTSoftware.Services -> CBTSoftware.Data
Then, you can continue referencing your services project from your web project:
CBTSoftware.Web.Host -> CBTSoftware.Services
You'll still be able to configure your EntityRepository in your Startup.cs file because it will know about your CBTSoftware.Data project transitively. Just make sure to remove the reference to your web project from your services project, since this is creating a cycle.
I have solved the problem by deleting the DbContext which i created in the Web Project and using the one which I created in another project which is a .Net Library then I added this line of code in my StartUp.cs file
services.AddDbContext<CBTDbContext>(options =>
options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));
By adding it, I was able to find the DbContext in the Web Project.
Then another problem has arisen when I'm trying to add migrations. Which I would open in another post
I also had this issue
In my case, I was using multiple projects in one solution. And in one of those projects, it's Dependencies was showing warning signs, within these Dependensies, there was a folder with included projects also each showing a warning sign.
I could solve it by right-clicking on the Dependencies, click on 'Add Project Reference' and then unselect all projects related to it/showing the warning signs.
After rebuilding, the cycle problem was gone.
I had a solution that contained two projects, one for the web layer that also contained the models, and another for a Windows forms project that did some other "stuff". The forms project referenced the web project, and all was fine up until I needed to reference something from the web project in the forms project, which I could not do for circular reference reasons.
So I created a new solution, put the data layer in one project and the web layer in another, so later on I could add the third project, and put in the references I need. Now when I run the web project, I get the following error;
So I understand that the web project is struggling to find my namespace from the data project, but I have referenced it, so I don't know what more to do.
***EDIT
This comes as no shock, but it's the view that's the issue. If I edit my Index.cshtml, it recognises the referenced project. I tried adding;
#using LottoData.Models
and intellisense completed as I typed. However, when I run it now, I get;
Help!
This was my bad. I forgot to change the output type for the data project to "Class Library", it was still set to "Console Program". Changed that, removed and re-added the reference, cleaned and rebuilt and it works fine now. Thanks #David and #Armand for your input.
I'm working on an MVC 3 project. I was told to get all the models and viewmodels out of the projects and put them in a class library so that they can be referenced from different types of projects. However, now that I've transferred all the viewmodels and models from the web project to a class library, and removed all the references to the web project, I cannot set reference to the class library from my web project with the reason stated in the question title. WHy is this happening? In my class library I'm not referencing the main project anywhere!!! Any suggestions? Thanks a lot!!
Experienced this earlier. Check the project that you are going to add if it has the reference to the project you are adding in it.
Example: Project A with reference to Project B. Then in Project B, you're adding Project A as reference.
well this usually happens for a reason, and this is that there is a cirrular reference,maybe not a direct one but an indirect one (through third project, how many projects do you have in your solution?).
In your library project remove all other projects references from solution, and try it again.
good luck
almir
I'm getting the following error:
error CS1704: An assembly with the same simple name
'Interop.xxx.dll, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=null has already been imported. Try removing one of the
references or sign them to enable side-by-side.
Everything I've seen says that I am referencing two assemblies with the same name and I need to remove one of them. However, I've checked and I'm only referencing it once.
This also only happens when I'm using msbuild to build from the command line on my dev box. If I build through Visual Studio or do a clean build on our CI server I don't see this error.
I've tried completely removing all of my source and building from scratch to more closely resemble the build machine but no luck.
So it looks like I can't read today!
The project had a reference to the Interop and a COM reference that generated the "same" interop. So there were two and I just didn't search very well. I still don't understand why it worked in other places but this did fix it.
In the Error List window, the project that was triggering this error was listed in the Project column. I got around the error by doing the following:
I unloaded the listed project (right-click => Unload Project)
Opened the XML for edit (right-click the unloaded project => Edit {ProjectName.csproj}).
Searched for the offending .dll, and noticed it was listed multiple times in the XML
Removed the entire Reference tag related to the offending dll, and did so for every copy of the reference except the first one listed
The reason it was listed multiple times was because several referenced libraries used that dll. This shouldn't be a problem, in and of itself, so I'm not sure what caused this error to suddenly pop up for me. I'll update this answer if I figure that out.
In my case the duplicate entry was caused by a NuGet package reference and a direct file reference to the same assembly in the packages folder. I am not sure how the project got into this state, but unloading the project and searching the XML file for the offending assembly name resolved the issue for me.
Note that in my case this started happening after updating a NuGet package to a newer version with no other changes to the project, so this maybe caused by a bug in NuGet.
If this is a web project, are there any strong-named references to the other version there? Those won't show up as a project dependency, but will cause a run-time error like you describe. Hope that helps
I had this problem but in my case, I had an old copy placed in the current folder for the EXE loading my component, that was loaded together with the current one, that was loaded by hand from my projects folder. Deleting that old copy solved my problem.
I used Debug > Windows > Modules window to see which modules were loaded at that time and that solved my problem.
For others facing the same as me: if building via command line using property AssemblyName, it will overwrite all assemblies generated by all solution projects - in other words, you will end up with (N -1) assemblies named the same where N is the no. of projects - the startup one (which generally will generate an exe).
This happens because all build command line properties are global and overwrite any project-specific setting. See this and this.
From the msdn link mentioned above:
Global properties are properties that are set by using the
/property switch on the command line, or properties that are set by
the integrated development environment (IDE) before a project is
built. These global properties are applied to all projects that are
built by using this Engine.
In my specific case, where Jenkins is the CI tool, I ended up adding a windows batch command at the end to rename the .exe only to what I originally intended when passing the AssemblyName parameter.
For those developing UWP projects that have project references that include specifically the Microsoft.Windows.SDK.Contracts nuget package (or other dependencies that reference it), this is a common error when the version of the SDK contracts is targeting a different version of the runtime to how your project is configured.
For instance, when targeting Windows 10, version 1903:
Any dependencies or reference projects should target or at least support the same runtime version.
it is common thought process to update all NuGet packages when a new stable version is available, but this is not always a helpful practise on its own. Just because a new stable version of a package is available does not mean that you should or that you can easily use that version.
Even though this package for SDK contracts has a stable update, it is not compatible with my main project configuration, Nuget does not know this so it allows the update.
This package is specifically designed to provide windows dlls for project types that DO NOT have windows platform targeting support, it copies the same dlls that are included by the UWP targeting config. By installing later versions of the package the references from the satellite project will be included in the output along with those provided due to platform targeting, ultimately causing OPs error.
There are similar SDK and targeting packs for Windows IoT Device Runtimes, this information should help you identify and resolve those issues if you get stuck on this issue as my team often does :)
In my case, the issue was on wrong characters in the ProjectReference section of my csproj file.
Background
I have a project that references another library I maintain, which I publish as a NuGet package.
Whenever I make changes to my library, I usually reference the local dll in my project to test and make sure everything looks good before I publish the library as a NuGet package.
When testing, I just comment out the PackageReference line and uncomment the ProjectReference one so it references my local dll, like so:
<ProjectReference Include="..\..\my-class-library\MyClassLibrary.csproj" />
<!--<PackageReference="MyClassLibrary" Version="2.0.1"/>-->
Root cause
I had the slashes inverted, so I was using / rather than \ in the path, like so:
<ProjectReference Include="../../my-class-library/MyClassLibrary.csproj" />
Once corrected, the issue went away.
Try this instead: remove Interop.xx.dll from the reference section in Solution Explorer and Rebuild the project
In our case this error was shown when we had a duplicate reference inside the .csproj file (although I have no idea how this happened).
The difference to an already posted answer is that, in our case, one was a project reference and another one was direct binary reference to a dll.
Once we removed one of those, project correctly compiled.
I have got a Visual Studio Solution containing several projects and have set up the references between the projects as project references.
When a reference to an assembly is added, the references' properties contain a setting for
Specific Version = True|False
This property is missing for project references. How can it be set? I'd like my solution to load any available assembly (no matter what version) in the bin folder.
I've had a problem when a workflow instance (Workflow Foundation) was deserialized and the dependencies were updated meanwhile.
I think the problem is that what you are asking is not possible directly with a project reference, I think that always implicitly turns into an 'explicit version', because of the nature of the link.
The way you could do this (calling the currently referenced project A, and the referencing project B):
Have the project you want to reference in your solution, just like you do now with the project reference
Explicitly set the dependency chain so the 'referenced' project is built first
Build the referenced project A once first manually
Create an assembly reference in project B to the results from the build in project A
Set the assembly reference to 'Specific Version = false'
The build order (dependency) will guarantee that A is always built before B, and B will reference it from the binary output directory of A.
(altho, it's a little brittle and I would not recommend it since it's easy to get wrong results if the settings are not all right, or the sun aligns with the stars wrong, or some such)
I might be misunderstanding your question, but when you add a project reference, the project's assembly is always loaded into any project that references it when the project is built. Therefore, you'll always have the latest available assembly in the bin folder for that project. VS treats projects differently than other assemblies in that regard.
You can add references to project output dlls instead of projects. Then you will be able to set Specific Version setting.
I have found the solution to my problem. It's described pretty detailed here.
The problem is not a matter of wrong project references, but more a de/serializing of workflow instances question.
Thanks to everybody who tried to help.