Develop Reference

Cycles detected

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.

Do binding redirects in app.config for class libraries do anything?

The VS solutions I often work with consist of a single executable project (console app, web app) and many class library projects that are all referenced by the executable.
When working with NuGet and installing packages, there's often an app.config file created for each project, usually containing nothing else than a list of binding redirects that consolidate versions of referenced assemblies. Sometimes there's some third-party library-specific content (like Entity Framework config section), but let's leave that aside for now.
When I build the solution and use the binaries of the main executable project, I see all the class library project assemblies in the build output together with the corresponding *.config files (the app.config file gets renamed to AssemblyName.config when built).
When launching the main executable, do the config files of the class library assemblies take any effect? Or is it just the app.config file of the executable that has an effect in this case? What if there are some binding redirects set up on some of the class library projects, and some different binding redirects set up on the main executable project — How are these combined, which take priority?
I've tried to research this online and from what I've read, it looks to me like the app.config files for non-executable assemblies are useless (with regards to binding redirects). Can someone confirm this or elaborate a bit more on the topic?
If it is that way, is it actually undesirable to have these app.config files created by NuGet in class libraries if they contain just the binding redirects? It feels to me that NuGet shouldn't create those binding redirects for class library projects, as it will only increase the confusion about what settings are actually applied.
I found these existing Stack Overflow questions on the topic, but their accepted answers are actually contradictory even when they're marked as duplicates of each other.
Why NuGet adds app.config with assemblyBinding to LIBRARY projects during a NuGet package update?
Is the bindingRedirect .config file needed or all assemblies in an application?
The accepted answer to the first question mentions that app.config files are actually used during compile-time, which means they could have effect. Sources like MSDN and MSBuild source code are cited there as a proof it's used during compile-time. Unfortunately, I'm not proficient enough in MSBuild to understand how it's being used, and if it's really a valid argument.
Can anybody describe an example scenario to prove that an app.config with binding redirects for a class library can do anything?

I have multiple applications with similar setup - Web application referencing multiple library projects each having their own nuget packages etc., Based on my personal experience the assembly bindings in the library projects are not considered during run time.
The bindings specified web or app config in the root application (web/console) is that only matters. All my library projects are setup with "Copy to Output Directory" setting as "Do not copy" for the app.config file - that way my output folder is not cluttered with dll and their config files.
Here is the link which says how the assembly is loaded and where is it being searched and the sequence of it. No where in the article they talk about individual project config files.
Hope that helps.

According to this old msdn article:
An application configuration file is an XML file used to control assembly binding. It can redirect an application from using one version of a side-by-side assembly to another version of the same assembly. This is called per-application configuration. An application configuration file applies only to a specific application manifest and dependent assemblies. Isolated components compiled with an embedded [ISOLATIONAWARE_MANIFEST_RESOURCE_ID] manifest require a separate application configuration file. Manifests managed with CreateActCtx require a separate application configuration file.
So only dll's with the ISOLATIONAWARE_MANIFEST_RESOURCE_ID set actually use an independent application config, otherwise it's deferred to the main process config file.
For more info on what ISOLATIONAWARE is you can read this other MSDN article that goes more in depth.
ISOLATIONAWARE_MANIFEST_RESOURCE_ID is used primarily for DLLs. It
should be used if the dll wants private dependencies other than the
process default. For example, if an dll depends on comctl32.dll
version 6.0.0.0. It should have a resource of type RT_MANIFEST, ID
ISOLATIONAWARE_MANIFEST_RESOURCE_ID to depend on comctl32.dll version
6.0.0.0, so that even if the process executable wants comctl32.dll version 5.1, the dll itself will still use the right version of
comctl32.dll.

The answer is maybe. Depending on the type of project the library file is. Some library projects run in contexts where the library's config file is respected (e.g. Azure Web Roles), but that is not the norm.
See my answer here for more details.

Generally there is only one configuration file and thats the configuration file of the executeable (.exe.config, web.config).
Any assembly redirects have to be placed in the configuration file of the executable.
Configuration files of dlls need to be loaded manually using the ConfigurationManager class. See also this question Equivalent to 'app.config' for a library (DLL)

No, only the app.config of the executable will have effect. For example, if you have a console app hosting a WCF service, and in your WCF service you make use of, for example, ConfigurationManager.AppSettings, the AppSettings will come from the console host app.config file. If you spin up another console application (ConsoleClient) to try connecting to the ConsoleHost, then in the parts where the ConsoleClient can be said to be "executing" (for example in its main method), it will use ConsoleClient's app.config, but as soon as it begins using the WCF service, the WCF service will delegate to use ConsoleHost's app.config. (Note that this last point is more relevant to the details behind WCF though.)
Surprisingly, msdn provided this great source:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/e13194df-6308-4cbe-973c-f6a462f43eae/how-can-wcf-library-dll-access-application-settings?referrer=http://social.msdn.microsoft.com/Forums/vstudio/en-US/e13194df-6308-4cbe-973c-f6a462f43eae/how-can-wcf-library-dll-access-application-settings?referrer=http://social.msdn.microsoft.com/Forums/vstudio/en-US/e13194df-6308-4cbe-973c-f6a462f43eae/how-can-wcf-library-dll-access-application-settings?forum=wcf

Error comes up when creating controller for ASP.Net Web API

I have just created a ASP.NET web API project with Visual Studio 17 and I have created a Class Library to connect it to an SQL database I created. the problem is when I try to create a controller in the project, I get the error,
There was an error running the selected code generator: could not load file 'ClassLibrary.dll' or one of it's dependencies. this system could not find the file specified.
Does anyone what the problem could be. I have looked at the folder where the said file should be contained in the ClassLibrary and it is empty.
I gather that it might be from my Entity Framework, I am using ADO.Net Entity Data Model.

For ASP.NET web API project no need to add Class Library:
Just right click in Solution and add ADO.net Model
Configure with Database
Add required Database Tables
Build solution

First you have to add reference of your class library project if you don't then just give a built to your project in which you added a reference of class library project, then try to create a controller it will definitely help you....

Best pattern for configuration management Asp.net

I always see that there are app.config's in dlls and then website has web.config.
At the run time mostly web.config passes data to all the portable libraries.
These configuration are passed as properties of portable library class. ConfigurationManager is used to get the values from config file.
Now the problem, In my current project they have configsectionhandler in webapp project/folder.
and my project folder structure is like
Main
WebApp
BusinessObject
ThirdPartyWebserviceCall
and as usual webapp project has reference to BusinessObject and BusinessObject has reference to ThirdPartyWebserviceCall.
Now if I want to use configsectionhandler in ThirdPartyWebserviceCall I will have add a circular reference to
webapp.
Does this design seem ok? It looks realy flawed to me.
Is there other standard pattern to access configuration values in the libraries.

ASMX page returning old Web Methods

I must be dumb (and i m sure i am making mistake but cant figure out at the moment)
Actually i deployed ASMX page containing reference to a Class Library which contains few web methods. It exposes those methods when i browse the site. But some how it is not showing me any further methods which i have added in it. The DLL is strong name assembly.
any clue plz?
I tried re adding the reference but there is no difference.
It worked but i dont know weather the files are not updated or references, so what i did, i removed the referenced ,deleted the files from bin and GAC and then re-added the files.After rebuilding , i deployed them again and it worked.

You need to update the web reference that you added to your project. If the class library contains the web reference, update the reference in it and then re-add/update your project's reference to the class library. If you don't update, then the only stubs/methods that your project will know about are the ones created when the web reference was first added.

Or is it something about GAC. If your class library assembly lies in GAC as an old version it won't be updated.