I have more than one .Net projects to work and i want to reference these all projects into one integrated project and add them as a reference in this project and want to run any method or function from this integrated project.So i have added all these projects in the same solution in the directory and added them to the solution and added as a reference.
Now My question
I havent converted those projects to class library as i want the main method to be there to kickoff that function from my integrated project ,if i make it class library will i still be able to access that main method???
I did add those projects reference and made them to class library and also as exe,but in both the cases , when i did import them ,but when i try to call those functions,it doesnt create an instance and doesnt show any options in intelligence,on top of that,once i try to build it back again,it throws an error "The type or namespace name could not be found(are you missing a using directive or an assembly reference?)"
Can someone please answer them !!!!
Internally there is little difference between a .NET exe and a .NET DLL. For most purposes a .NET .exe is just a .NET dll with some data saying "this class has the main function". It is one of those things they copied really well from Java and improoved upon.
There might be secondary differences (I am not sure the .exe provides full COM/.NET interop support, for example). But for most purposes, you can use a Compiled .NET exe like a compiled .NET dll. Including putting it into the references of a 3rd project.
The main issue here is that only the compiled code in the propert directory is considered. Especially if you still plan on working on those backend References, you need to be aware if you referenced the Debug or Release version of the .dll/.exe
I know the error message is common and there are plenty of questions on SO about this error, but no solutions have helped me so far, so I decided to ask the question. Difference to most of similar questions is me using App_Code directory.
Error message:
CS0012: The type 'Project.Rights.OperationsProvider' is defined in an
assembly that is not referenced. You must add a reference to assembly
'Project.Rights, version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.
Source File:
c:\inetpub\wwwroot\Test\Website\App_Code\Company\Project\BusinessLogic\Manager.cs
Following suggestions here and here, I have deleted all instances of Project.Rights.dll inside C:\Windows\Microsoft.NET/*.*
According to this, I checked if .cs files in question have build action set to "Compile". They do.
I have also double checked that the .cs file containing the "Project.Rights.OperationsProvider" type is deployed to App_Code directory.
For some reason, application is not looking for the type in the App_Code directory. Since I've deleted all instances of Project.Rights.dll (that I know of), I don't know which assembly the error message is mentioning.
When you get this error it isn't always obvious what is going on, but as the error says - you are missing a reference. Take the following line of code as an example:
MyObjectType a = new MyObjectType("parameter");
It looks simple enough and you probably have referenced "MyObjectType" correctly. But lets say one of the overloads for the "MyObjectType" constructor takes a type that you don't have referenced. For example there is an overload defined as:
public MyObjectType(TypeFromOtherAssembly parameter) {
// ... normal constructor code ...
}
That is at least one case where you will get this error. So, look for this type of pattern where you have referenced the type but not all the types of the properties or method parameters that are possible for functions being called on that type.
Hopefully this at least gets you going in the right direction!
Check target framework in the projects.
In my case "You must add a reference to assembly" actually meant, that caller and reference projects didn't have the same target framework. The caller project had .Net 4.5 , but referenced library had target 4.6.1.
I am sure, that MS compiler can be smarter and log more meaningful error message. I've added a suggestion to https://github.com/dotnet/roslyn/issues/14756
In my case this was because doing a NuGet package update had only updated references to a dll dependency in some but not all projects in my solution - resulting in conflicting versions. Using a grep-style tool to search text within *.csproj files in my solution it was then easy to see the projects that still needed to be updated.
When you get this error, it means that code you are using makes a reference to a type that is in an assembly, but the assembly is not part of your project so it can't use it.
Deleting Project.Rights.dll is the opposite of what you want. You need to make sure your project can reference the assembly. So it must either be placed in the Global Assembly Cache or your web application's ~/Bin directory.
Edit-If you don't want to use the assembly, then deleting it is not the proper solution either. Instead, you must remove all references to it in your code. Since the assembly isn't directly needed by code you've written, but instead by something else you're referencing, you'll have to replace that referenced assembly with something that doesn't have Project.Rights.dll as a dependency.
In my case, I was referencing a library that was being built to the wrong Platform/Configuration (I had just created the referenced library).
Furthermore, I was unable to fix the problem in Visual Studio Configuration Manager -- unable to switch and create new Platforms and Configurations for this library. I fixed it by correcting the entries in the ProjectConfigurationPlatforms section of the .sln file for that project. All its permutations were set to Debug|Any CPU (I'm not sure how I did that). I overwrote the entries for the broken project with the ones for a working project and changed the GUID for each entry.
Entries for functioning project
{9E93345C-7A51-4E9A-ACB0-DAAB8F1A1267}.Release|x64.ActiveCfg = Release|x64
{9E93345C-7A51-4E9A-ACB0-DAAB8F1A1267}.Release|x64.Build.0 = Release|x64
Entries for corrupted project
{94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.ActiveCfg = Debug|Any CPU
{94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.Build.0 = Debug|Any CPU
Corrupted entries now fixed
{94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.ActiveCfg = Release|x64
{94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.Build.0 = Release|x64
I hope this helps someone.
It just happened to me that different projects were referencing different copies of the same dll.
I made sure all referenced the same file on disk, and the error disappeared as I expected.
Unloading and reloading the class library in Visual Studio solved this for me.
For me, this was caused by the project both directly and indirectly (through another dependency) referencing two different builds of Bouncy Castle that had different assembly names. One of the Bouncy Castle builds was the NuGet package, the other one was a debug build of the source downloaded from GitHub. Both were nominally version 1.8.1, but the project settings of the GitHub code set the assembly name to BouncyCastle whereas the NuGet package had the assembly name BouncyCastle.Crypto. Changing the project settings, thus aligning the assembly names, fixed the problem.
It didn't work for me when I've tried to add the reference from the .NET Assemblies tab.
It worked, though, when I've added the reference with BROWSE to C:\Windows\Microsoft.NET\Framework\v4.0.30319
I had this issue on a newly created solution that used existing projects. For some reason, one project could not "see" one other project, even though it had the same reference as every other project, and the referenced project was also building. I suspect that it was failing to detect something having to do with multiple target frameworks, because it was building in one framework but not the other.
Cleaning and rebuilding didn't work, and restarting VS didn't work.
What ended up working was opening a "Developer Command Prompt for VS 2019" and then issuing a msbuild MySolution.sln command. This completed successfully, and afterwards VS started building successfully also.
one of main reason can be the property of DLL
you must before do any thing to check the specific version property if it true make it false
Reason:
maybe the source code joined with other (old)version when you build it , but this Library upgraded with new update the version now different in the Assembly Cash and your application forbidden to get new DLL ,and after disable specific version property your applacaten will be free to get the new version of DLL references
Maybe a library (DLL file) you are using requires another library. In my case, I referenced a library that contained a database entity model - but I forgot to reference the entity framework library.
This can also mean you use a library, which exposes (public) types that are defined in a library. Even when you do not use these specifically in your library (the one that doesn't build).
What this probably prevents is you writing code that uses a class (which in its signature has the types from a library not referenced) that you cannot use.
For me the reason why the error appeared was that the WebForm where the error was reported has been moved from another folder, but the name of its codefile class remained unchanged and didn't correspond to the actual path.
Initial state:
Original file path: /Folder1/Subfolder1/MyWebForm.aspx.cs
Original codefile class name: Folder1_Subfolder1_MyWebForm
After the file was moved:
File path: /Folder1/MyWebForm.aspx.cs
Codefile class name (unchanged, with the error shown): Folder1_Subfolder1_MyWebForm
The solution:
Rename your codefile class Folder1_Subfolder1_MyWebForm
to one corresponding with the new path: Folder1_MyWebForm
All at once - problem solved, no errors reporting..
The type 'Domain.tblUser' is defined in an assembly that is not
referenced. You must add a reference to assembly 'Domain,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.
**Solved:**
Add reference of my domain library layer to my web app libary layer
Note: Make sure your references are correct according to you DI container
In my case this was because I used
Implicit Operator
between BLL and DAL classes.when I want to use BLL Layer In Application Layer I got this error.
I changed
implicit operator
to
explicit operator
it be OK.
Thanks
In my case the version of the dll referenced was actually newer than the one that I had before.
I just needed to roll back to the previous release and that fixed it.
I have a similar problem, and I remove the RuntimeFrameworkVersion, and the problem was fixed.
Try to remove 1.1.1 or
My problem was that the Output Type for one of my projects was set to Console Application. To fix this, I right-clicked the project, chose Properties, clicked the Application tab, and change Output Type (from Console Application) to Class Library. After I re-compiled, this error went away.
Clean your solution and rebuild worked for me (in Visual Studio, these are options you get when you right click in your solution explorer), the error is gone in my project.
I may not be asking this question correctly as I haven't been able to find a reference here or on Google. I need to modify a class that is in one of my reference DLL's. Will VS look at the reference DLL first or the local file first ? It seems to look at the reference DLL first. Is there a way to tell VS which to look at first ?
Thanks
Clarification - I have a class definition in the reference DLL and also in a local project file. The local project file is the class definition that I need the program to use.
Using an alias on your references, you can specify which of two similarly named classes you are referring to in your code.
This is explained by Jon Skeet here:
What use is the Aliases property of assembly references in Visual Studio 8
Limitations
This will only help you, if you instanciate that class yourself. It is not possible to let a foreign assembly create instances of your own class if there is no dedicated mechanism (i.e. API) for doing so.
Your question is quite vague, but if you use the Fusion Log Viewer FusLogVw.exe (just search for it on your computer) you can see what dlls are loaded and which paths were used to look for it.
This depends on how you setup your reference to the project in question. Visual Studio has 2 concepts of references.
Project to Project
Project to DLL
For the sake of this discussion lets call the main project A and the referenced project B (the class to change is located in B)
If there is a project to project reference from A to B then the build is always against the latest source code. Hence if you change the class definition A will always build against the changed class.
If there is a project to DLL reference from A to B then things are a bit murkier. There are so many possibilities here that it is hard to speculate intelligently what will happen. It may get the updated class, it may not, it may after a second rebuild.
In general though if you have 2 projects in the same solution and one references the other you should always use a project to project reference. The easiest way to guarantee this is to delete the reference, right click select add reference and go through the project route instead of "Browse".
I am working on a existing c# class library project. I want to add few more class to it. This is then used in a new project. I have added the required classes to the existing typelib project, but when I refer the typelib in the next project and try to access the newly added methods it showing error
The type or namespace name 'abc' does not exist in the name space
xyz.TypeLib.core (are you missing assembly reference)
but I can access all those classes which existed previously in that project. I am having issue with newly added files.
Here are the steps I did,
added new classes to the existing project.
Build the project
Added dll to next project from the bin folder of the class library project
Also, as a test I also tried adding a new method in one of the classes which I can access, but this method is not avaiable!
How can I do this properly?
1.) Make sure you have added the correct DLL to the project. Therefore, clean the library project, build it, and use that DLL.
2.) (this will most likely be the problem): In Visual Studio, click on the DLL and in the properties, make sure that "Copy to output directory" is set to "Copy if newer".
3.) Re-add the reference to the file.
4.) Clean and then build again your new project that uses the library.
If the two projects are in the same Visual Studio Solution, the correct approach is to add the class library project directly as a reference. This will bypass any possible dll mismatching that can be caused by other approaches.
I'm reworking someone else's code, where they had a helper class with way to much code that shouldn't be there (data access, business logic, everything had slowly been shoved in there).
I've moved the relevant code into the appropriate pre-existing classes and created a separate, brand new helper class in the appropriate project, but all my references to this class simply don't work.
Here's a simple view of how my class looks (names slightly changed);
namespace Company.Web.Application.Reporting
{
public class ReportHelper
{
here I have a bunch of methods
}
}
and here is how it is being referenced;
using Company.Web.Application.Reporting;
namespace Company.Web.Application.App.Reports
{
public partial class PlansReports : PageBase
{
//This is the problem part
private ReportHelper Helper = new ReportHelper();
heaps of other code with no problems here...
}
}
My problem is that the I get the following error, everywhere that I try to access my new helper.
The type or namespace name
'ReportHelper' could not be found (are
you missing a using directive or an
assembly reference?)
All my using statements are there, I have the appropriate references in each relevant project, yet this still persists.
At this point I am totally stuck, I just need to get this referencing issue sorted out so I can ensure all my helper methods work correctly.
Any help is greatly appreciated,
Pat.
OK, I found the problem (actually a colleague did)
This original Helper class was contained in the app_code folder of my main project, which as I have just learned, handles compiling differently to all other folders in a project.
Code in here is compiled at run time, rather than during the build.
When I created my new classes, they were in the app_code folder because I used code rush to extract the class to a new file, which kept it in the same location...after which I moved them to their "sensible" location.
Unfortunately they still had the build action of "Content" inherited from their previous presence in the app_code folder.
So, on the new class file, I simply changed its build action to "Compile" and now all is well with the world.
Cheers,
Pat.
Is your ReportHelper in a separate project or DLL? If so have you added this project/dll as a reference? (In your solution explorer under References, check your project/dll is there.
Have you built Company.Web.Application.Reporting so that the type would be known? That would be my idea along with ensuring that the dependencies are set up properly.
It sounds like you know what you are doing and everything looks right, so it has to be something simple. Are you trying to access changes in ReportHelper that haven't been compiled into the dll? I would try rebuilding the reference assembly; every time you make changes to that assembly, it needs to be rebuilt.
Also verify you are adding the correct assembly (e.g. Debug vs. Release) to your project. It doesn't matter which type, but you don't want compile new changes into the Debug dll, and keep adding the old version of the Release dll.