I'm writing an application in .Net 3.5.
I have 3 projects in the solution so far. When adding the references to the other projects from my main project, the intellisense manages to find the classes from the other project's dlls but at compile time it seems to be "loosing" the reference.
This might be because I initially created the project with target framework .Net 4.0. However since I needed to use the ASP.NET web services I had to downgrade to 3.5.
Any help will be greatly appreciated.
The referrenced projects must be Copy Local : True
Referrence -> Properites ->Copy Local : True
Batch clean all projects in your solution, make sure all the projects in your dependency graph target the .NET 3.5 framework. Check the reference's HintPath in your .csproj file (open with text editor) for references to external DLLs and make sure they're all <=3.5.
However since I needed to use the ASP.NET web services I had to downgrade to 3.5.
There are also several different web service projects in .NET 4. I don't quite understand this move.
You have project references, intellisense sees your referenced classes but when compiling, the compiler seems not to find the referenced assemblies.
I see two possible reasons for this behaviour:
Your main project references a lower version of the .NET framework than your library projects (this is the most likely cause).
Your library projects won't get built at all / or in the wrong order (check the settings in the configuration manager. Open it with a right click on your solution in the solition explorer).
Related
I am facing a weird problem. I have multiple .net standard class projects in my solution. There is one .net standard 2.0 class library project called Messaging (.csproj) which uses ActiveMQ to push and read data from it. This project reference to Apache.NMS library. Now I have another project called Core (.csproj) which references to the Messaging project. During the constructor call of the class inside Messaging project in Core project, I get the error that System could not find Apache.NMS dll. If I add this reference in the Core project then everything works fine but I really do not understand why this is happening. With a pure .net framework thing, I never faced this issue. Separate projects with their own references and working independently.
Can anyone help with it?
I have added all references from nuget
After lot of research i found the solution of this problem. What was happening is in the bin folder of the .NET framework / standard project the dependent dll of the referenced projects were not getting copied.
Solution for .NET Framework project:
Open .csproj file and add below line in the first tag
<RestoreProjectStyle>PackageReference</RestoreProjectStyle>
Solution for .NET Standard / Core project:
Open .csproj file and add below line the first tag
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
Now compile the projects and you will see all the required dll's are present in the bin folder.
Hope this help someone else who is facing the same issue.
I would like to know how I can share c# source codes between two (or more) .NET Core projects (commandline projects!).
As far as I understand, I can not link to source files in different directories in xproj/project.json based projects. I noticed that it now seems to be recommended to create nuget packages for everything. But is it really necessary for me to setup a private repository and create a nuget package only to be able to share some common source units?
VS2015 contains a template for .NET Core library which may be suitable for building a shared lib. Is it possible to link this lib to a project without a nuget package?
.NET Core Library is an excellent solution for you.
Do it the same way as in standard C# solution - just create the project and reference this project or add a reference to DLL file.
You don't need to use a Nuget, for your own purpose. Nuget packages could be useful to distribute your dll outside.
Clarification:
I miss one point - I'm using VS2015, but I have included Class Library project in my solution, and I'm referencing by project, not by DLL file, and this works fine in ASP.Net Core.
I also have a different project, where referencing DLL file directly working fine, but this is the previous version of ASP.NET app (not Core) - seems NET Core doesn't support this way like as the previous version (yet?).
Sorry for confusing you, sometimes it's too many technologies ;)
So could you just include ClassLibrary project into solution with your project and refer it as a project?
I have achieved this by using source control to branch from my commonly used projects in each new solution, and again merging back to the master branch if I make any changes.
Alternatively, baring in mind that NuGet is only an archived collection of files, you could keep this NuGet package locally, or even create a Template for Visual Studio that has the common libraries by default.
There are a wide range of possibilities that are down to your preference, and current environment state (I.E: Able to setup Source Control, or a package repository).
Could not find an answer to my doubts and hopefully somebody can clarify.
I Have created a dummy solution with
1 class library(.net framework)
1 .net core library
Tried to reference either way but I cant,they are not compatible,fine makes sense.
Now my question
I have a utility class library(.net framework)with extensions,helpers etc...
that is used by winforms-wpf-asp.net mvc 4,5 apps now with the event of .net core it looks to me that I cannot use this library anymore unless I port it to .net core,which then i cannot use with my other apps.
What is the correct approach?
Am i missing the obvious?
Sharing code between a normal .NET library and a Core project did not work for me via simply using a Shared project, because I could not reference it from the Core project.
However, with a little trick I could make it work.
Let me explain with this folder/file structure:
[ProjectName] // Root of Core project
project.json
[ProjectName].xproj
Shared // Root of Shared project
[ProjectName].Shared.projitems
[ProjectName].Shared.shproj
// -- Source files here --
Net // Root of .NET project
[ProjectName].csproj
Properties
AssemblyInfo.cs // For both Core and .NET project
// NO source files here
So, you will need 3 projects, of course: a Core project, a normal .NET project, and a Shared project.
The Shared project has all the source files.
The .NET project references the Shared project, so it also has those files.
The Core project sees all the files the Shared project has, so it also has the same files.
That's it. You now can have common source code files for the .NET and the Core project.
A few notes:
Do NOT ever put the .shroj and the .csproj into the same folder. For me, it totally turned off intellisense in VS (2015). This information costed a lot of pain for me...
You can use #if -s to fine tune the common code
You can also use NuGet 2 in the .NET project with the above folder structure.
Note, that if you'd put the (NuGet 2) packages.config into the same folder where the (NuGet 3) project.json is located, the latter would totally overwrite the earlier.
You could try to use a shared library project. It compiles against the platform of the referencing application/library, so to speak. That gives you the ability to create class libraries targeting different platforms without the need to duplicate any code, but it may require some #if...
https://blogs.msdn.microsoft.com/dotnet/2014/04/21/sharing-code-across-platforms/
I've got a Solution with lots of projects and all but one of them is behaving. The one that is not working is a ConsoleApplication, and it relies on C# Class Library project. I've added a reference to the library project, and add the namespace (which I've checked is correct), but everywhere I reference the classes in my library, I get:
The type or namespace 'MyClass' could not be found (are you missing a using directive or an assembly reference?).
The library project is building successfully (I can see the DLLs appear in the bin folder) and I've tried a project reference, and also a reference to the DLL itself. Neither works.
Also, all projects are set to build with a platform target of 'Any CPU'.
I've tried pretty much every suggestion I've come across on forums with no success. Can anyone shed some light on what's going wrong?
Thanks
This solved the problem:
The console application had a Target framework of .NET Framework 4 Client Profile, whereas the library just had .NET Framework 4. I set the console app to .NET Framework 4 and it all builds perfectly.
My bet is on a framework mismatch between your library and you app...
Check if your library is not building with a superior version than you app, or if your app is building with a Client profile flavor
It is probably that one of your DLLs references some part of the .net framework that is not referenced in your console application. For example if one of your class library projects has asp.net server controls in and references System.Web, but your console application does not reference System.Web it will not build and you will get that error. But it is not obvious because the DLLs referenced are stored in the GAC so they would never appear in your bin folder.
I had to simply restart visual studio for reference to work but make sure you have reference added in .csproj file.
If you still experience the issue, make sure the class you're referencing is public and that Asp.net core Framework version match.
Sounds weird,
Have you tried to remove the reference of the project and add it again? Check if your console app has got all the right references.
You could also inspect the .csproj file and see if everything is correct in there.
Just Check that you "Class Library" project has classes in it or if it is a data access layer project which include only a .edmx Model check the Model designer is found and it generates fine.
Good Luck
I worked with syncing the framework, but still, it was giving issue.
So I tried another way.
Right-click on the dependency, and select Add project reference. I added the required project then the error was gone.
I have 2 projects in a solution, 1 a dll, the other an exe. Both were using .net version 4.0 however no 4.0 specific libraries were used so it should be possible for me to safely change them to 3.5
I did this under both project properties, I built the dll fine. Now when i try to build the exe it cannot find the dll's namespace. I have readded the reference, but it still cant see it. When I reverted the .net version it did say I might have to modify the project files before it builds. I have tried to search for a solution via google but the key words I am using are too commonly used. Can anyone advise?
Many thanks, Chris
Edit:
Tried the following already..
Reference DLL specifically whilst ensuring not 4.0 copy
Delete bin and obj folders
Restart VS
Rather than referencing the output DLL, have you tried setting it as a project reference instead.
Also, have you done a clean build of the solution incase any .Net 4.0 files were lingering? You can manually clean the project by deleting the bin and obj folders.
Have you tried removing the projects from the solution, creating a new .net 3.5 project and compiling that. Then add in the ddl project (Add -> existing project) and compile, then add in exe project without reference, compile then add in the references.
Odd question, but have you check the name spaces still. Can you call in your project the namesapce, i.e. using mydllproject.model.myengine
I would open your project files as XML. To do this, close the soltion and reopen the projects only by clicking the down arrow on the File/Open button and selecting Open With... XML (Text) Editor. Check to make sure each project has a ToolsVersion="4.0" in the header. Check the RootNamespace and TargetFrameworksVersion elements to see if they have the values that you expect. At the bottom of the file, check the ProjectReference element within the ItemGroup. Make sure the GUID in the project reference matches the GUID that is defined in your solution file.
Finally, make sure you clean your project before you rebuild it. If you're using source control, check out the project into a new, empty sandbox.
Good Luck!
-Put dll and exe in 3.5
-Compile the dll only
-Delete the reference to the dll and readd it
-Rebuild the solution
Check the DLLs that you are referencing what kind of target runtime they require, especially the "Engine.dll". You could do this with the .NET Refractor for example. If they are compiled for v4.0, then yuou need to get versions for an earlier version of .NET runtime.
I had a very similar problem to this. In my case it I had two projects, a 'class library' and a windows forms application in the same solution.
After changing the target framework of both the projects to .NET4.0 framework, and adding a reference to the class library in my windows forms application, it wouldn't detect the namespace of my class library.
Here is what I did that finally solved the problem:
Created a new project with .NET 4.0 framework as the target framework. I imported all my forms and classes into this project from the original solution.
Added the existing class library as a new project.
Added a reference to the class library project from my windows forms project
For each of the class files under the class library project, I set the 'Build Action' to 'Compile'
Right-clicked the class library project and selected to 'Rebuild'.
Then when I go into my windows forms projects, I can see the namespace when I use the
'using namespace_name' statement.
Note: Maybe you do not need to create a new project like I did in the first few steps. But changing the Build Action definitely did the trick.
Hope it helps.