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.
Related
I'm not new to C# programming, but I suppose I'm new to programing "the right way" in C#. I've worked in C on embedded devices for years and have written desktop apps to support them. First in VB6, then in C#.
I recently started making better use of classes for reusing code (and for instantiating more than one instance of the class in a program). For example, I "wrapped" a UART interface with some additional functionality so I can use the same code for multiple ports by creating an instance of the class for each one.
It is in a separate file, but still in the same program namespace, so when I want to reuse it, I have to copy the file and change the namespace to the new project.
I'm sure there's a way to create it such that I can just reference it like everything else with either a "using..." reference at the top of the program or with a "Project | References..." checkbox. But for the life of me I can't find a good learning journey for this.
Any direction would help.
You want to create your reuseable class in an assembly - this is the equivalent of a dll from your C experience.
To create an assembly, have a separate project of type assembly (instead of exe) . You can reference the assembly from other projects. If your project is in the same solution you can reference the project, otherwise you can reference the compiled assembly.
C# uses a packaging system called Nuget, so you can package your assemblies into "Nugets" which you host in a Nuget Server. You can then use tooling to discover and import these.
Please create a Class Library project and include your class into that project. Make sure your class is public. Once you build this project you'll get an assembly which can be referenced from other projects. See Tutorial: Create a .NET class library using Visual Studio
There are different ways of referencing it.
You can have the class library project in the same solution as the main project. In this case you should add a project reference.
You can copy the compiled *.dll file to some folder in your solution (e.g. Lib) and add an assembly reference.
If this assembly is to be used in multiple projects please consider creating a NuGet package with this library and pushing it to some repository. Then other projects can add a package reference to this package.
Details:
How to: Add or remove references by using the Reference Manager
Install and manage packages in Visual Studio using the NuGet Package Manager
It is in a separate file, but still in the same program namespace, so when I want to reuse it, I have to copy the file and change the namespace to the new project.
Well, it isn't the best practice but (unfortunatly) still a common behavior. So don't worry to much about it.
What you could do to improve it place the file (and other reusable parts) in a seperated csproj.
For example name the project of the type class library and name it VinDag.Tools. Within the project create a folder UART and place the wrapper there. The namespace of the wrapper would then be VinDag.Tools.UART.
From know on you can just reference the class library instead of renaming the file. It's not necessarily required to be the same namespace as the project.
From there you can start considering (private) nugets. This would prevent you from copying files/csproj around.
I need to implement a wrapper to expose some native C++ code to C#, and have followed this tutorial:
http://www.silverlightshow.net/items/Windows-Phone-8-Native-Code-Support.aspx
So far in my C# test project, I don't have problems instantiating a class written in C++/CX from the Runtime Component project and using methods from that class, so long as I reference the entire project (.sln).
Visual Studio doesn't allow me to reference the Runtime Component DLL alone, but does allow me to reference the .winmd file in the project. C# then recognizes the namespace correctly, however at runtime I get a TypeLoadException when trying to create the same object.
This doesn't appear to be a namespace problem (as mentioned here: Changing namespace name of C++ component in Windows Phone causes exception), since everything is alright so long as I create a project reference (or does referencing a project vs a .winmd affect the namespace somehow?).
Is it possible to bundle the Runtime Component in some form that an end user can reference it without needing to provide the entire project?
You need to add following the to WMAppManifest.xml
<ActivatableClasses>
<InProcessServer>
<Path>YourComponent.dll</Path>
<ActivatableClass ThreadingModel="both" ActivatableClassId="YourComponentNamespace.YourComponent"/>
</InProcessServer>
</ActivatableClasses>
With YourComponent being the name of your WinMD.
I think what you are seeing is a manifestation of the problem described here.
In short, when creating a WinRT component using C++, just referencing the output DLL or the output winmd is not sufficient. You need both.
I had this same problem, and (eventually) figured out that the .dll and .winmd file needed to have the same name (which was the same as the namespace they defined) and be in the same directory.
For example, if your classes are in the X::Y namespace, the files must be X.Y.dll and X.Y.winmd.
Then all I needed to do was add a reference to the .winmd file in my project (by right-clicking on the References folder for that project in the Solution Explorer, choosing "Add Reference...", then choosing "Browse" from the dialog that comes up). I didn't need to add anything to the manifest file.
I have a project ProjectA in which I am keeping utility classes. I want to use this project in multiple solutions so I do not have to copy files, link files and update files every time I make changes in classes of Project.
But there seems to be a problem: if I am referencing ProjectA in ProjectB, the compiled application of ProjectB can not run unless there's a compiled application from ProjectA next to it. So if the output of ProjectB is ProjectB.exe, ProjectB.exe gives an error upon execution if ProjectA.exe is not next to it. Why is that? I just want to use namespaces from ProjectA in ProjectB, I do not need ProjectA to depend on a compiled version of ProjectB.
Can anyone tell me how to reference ProjectA in ProjectB without needing the output of ProjectA to run the output of ProjectB?
You probably need a shared dll.
You have created utility classes in project A out because they are shared all across project A (Application A?), now you have introduced project B (Application B) and as you state it needs to get hold of the code from projectA.dll/exe.
So create a new project in your solution (Ab.Shared.dll maybe:-)) and move your utiilty classes into it. You can now reference that dll from both project A and project B.
Update: Just read about your comment about sucking code out.
The shared dll is the most common way of sharing the code about, but there are other ways. Theoretically you can simply "include" the same *.cs files in both projects and share them that way (use the drop down on the Add existing item dialog and select Add as link) . However in practice it becomes more awkward maintaining this scenario so most people use a shared dll.
Namespaces are not restricted to one assembly - you can use the same namespace across several assemblies if you wish, and one assembly can contain as many namespaces as you like.
If you are referencing a class/type from another assembly, then that assembly must be present (or locatable) when you run the original assembly. If all you are doing is coding then a simple project reference in your solution will do the trick. If you don't have the source code to Project A then you will need it in its compiled form - without it the CLR cannot inspect it and know what it contains.
In that case add the ProjectA compiled dll in your bin folder and add the reference to that dll from your other project. Do not add reference to your ProjectA project.
When you add reference to the project using Visual studio, Add Reference -> Projects, then it requires the project to be compiled and it copies the dll/exe to the other project bin folder.
Open your csproj file in text editor and insert xml:
<Reference Include="AssemblyName.dll">
<HintPath>$(EnvironmentVariable)\bin\AssemblyName.dll</HintPath>
<Private>False</Private>
</Reference>
If I understand correctly, you have code in ProjectA.exe that you want to use in ProjectB.exe, but at run time, you'd like to run ProjectB.exe without requiring the user to have a copy of ProjectA.exe.
This is not possible. When you use a type from another assembly, that assembly is loaded at run time. The type is not copied from ProjectA to ProjectB.
It sounds to me like you should extract the common utility classes into ProjectUtility.dll, and then reference that from both your ProjectA.exe and ProjectB.exe applications.
EDIT: ILMERGE might be the way to go. See Linking statically in C# for more information.
Visual Studio 2008(C#).....I have 3 project in one solution(win application). In every project I've been signing using project properties signing tab to one MySigned.snk. How to manage build configuration so my project doesn't error on every build?
I use [assembly: InternalsVisibleTo("MYproject1, PublicKey=.....")] properties so the other project class can access internal class of base class on other project.
Error becasuse I used backgroundprocess to update every form on my project.But on development environment what suppose I have to do so The project safely on during development? thx before...
I use [assembly:
InternalsVisibleTo("MYproject1,
PublicKey=.....")] properties so the
other project class can access
internal class of base class on other
project.
This is not related to the issue.
In every project I've been signing
using project properties signing tab
to one MySigned.snk. How to manage
build configuration so my project
doesn't error on every build?
I assume it is because the assembly versions are auto-incrementing:
Use project references always. This way, you will make sure everything is built against latest version numbers
Removing * from the AssemblyInfo's assembly version attribute will help here but it is advisable to keep it there.
Why one project (exe) does not see the namespace of another project (dll) in the same solution?
You need to add a reference from the using project to the DLL first.
Select Project|Add Reference, Projects Tab.
A "solution" in Visual Studio is a collection of projects. Each project is independent of all the others. The solution is just a convenient way of organizing projects and opening them all together.
If one project is going to use the public objects defined in another project, then it must be compiled with a reference to the other project. This is true whether the projects are part of a single solution or not.
To signal to Visual Studio that the EXE must be compiled with a reference to the DLL, you must add the DLL to the EXE's list of references in the Solution Explorer.
You need to add a reference to the DLL.
Right-click the EXE project, click Add Reference, go to the Projects tab, and select the DLL.
Also, make sure that the classes in the DLL are public.
Sounds like you need to add a reference to the dll
Right click on the project --> Add Reference