I've created a simple library project to use in another monotouch project. When ProjectA References LibraryProjectB.csproj, it works perfectly. However when ProjectA references the .dll created by LibraryProjectB (LibraryProjectB.dll), I get a couple of compiler errors such as "Compiler Error, method __ does not exist"
Why does directly linking the project work while the DLL that the project creates causes errors?
This is because your build steps get out of order when you do this. So you add a method to your library, and use it in your project. Well, your app could get built first--and then not be able to reference the new method.
You need to reference the project directly.
Related
I have a behaviour when importing a C# dll into another C# solution.
The dll I'm trying to import is a class library that I've previously implemented for another project and in which I made some improvements during time.
The dll compiles just fine and after I've imported it into the new solution the classes and methods are found by intellisense.
The problem is when I run the project in which the dll is imported and a TypeLoadException is throw (the message is something like "Unable to load type 'xyz' from assembly ...".
I've already tried to delete the .vs folder and clean and rebuild the solution (both).
I have also tried to decompile the actual dll to seeif there is something strange, but the classes and methods are actually there.
Thanks all.
I was importing the same dll on 2 different projects of the new solution and (I still don't know why) one project had an old reference to the dll (even if the reference was directly to the file).
Even if the method existed in the new reference, visual studio was loading the old one.
Removing the old reference and adding it again solved the problem.
There is a project that implements a dll. There is another project that uses that dll, let's call it "calling" code. For both there is available the source code.
Is it possible to easily integrate into the calling code the source of the dll in order to change/debug together both and then to separate again to build exe and dll so that one can run the exe which will call the dll?
Now I am doing in such uncomfortable way : I add the source of the dll to the project of the calling code, modify, build everything and test/debug.
When everything is ok I remove dll source from calling project, cut and paste it into the dll project. and build the dll. Finally I add the reference to the dll into the calling project, then build. I guess there is a better way.
I have compiled our editor scripts into a single .dll file, and put it in /Assets/Editor directory:
These extended script menus are shown in editor correctly:
But it has this TypeLoadException when I click the menu. The type 'Util' is actually in 'UnityVS.x3dgame.CSharp.csproj' project, which is also a library project.
TypeLoadException: Could not load type 'Util' from assembly 'EditorLibrary'.
Scene2DBundleTool.GenerateSceneEffectLuaEditor ()
I have no idea how to solve this.
Here is some more information:
Solution structure:
EditorLibrary references:
Help wanted.
You get this error because you did not build the dll it properly. If you want to include Unity's API in your own dll, you must add also add Unity reference to the dll so that your dll can use those API.
You must the basic references such as, System, System.Core and System.Xml.
Now, you must add Unity's references to your dll project before build the dll project. The dll reference to add depends on where the Unity API came from.
Standalone API:
UnityEngine.dll - from C:\Program Files\Unity\Editor\Data\Managed
Editor API:
UnityEditor.dll - from C:\Program Files\Unity\Editor\Data\Managed
UI:
UnityEngine.UI.dll - from C:\Program
Files\Unity\Editor\Data\UnityExtensions\Unity\GUISystem
[Editor features]:
UnityEditor.UI.dll - from C:\Program
Files\Unity\Editor\Data\UnityExtensions\Unity\GUISystem\Editor
Finally, make sure to select the proper .NET framework in your dll project before building it. .Net Framework 2.0 should be fine.
Our Unity's path may be different but once you find the root path where it is installed, everything else is the-same.
Note:
When I said, add reference, I meant add reference to the library project you are building not to your Unity project. From Visual Studio, this can be done by going to Projects ---> Add Reference... ---> Browse...(Button) then select the appropriate dll file.
I have two separate C# projects,
A C# project is only used as a dll reference
A C# project with 1st project as dll reference.
Now I need to clean up the old methods of 1st project which is used as a dll reference.
How can I find the functions/ methods that I am actively using/ calling from the 2nd to 1st project.
I would comment out the Using reference to Project 1, then see which lines generate compile errors. That's where the references are used.
If you use Visual Studio, you can find them all if you install Resharper:
Expand the References and choose Find code Dependent on Module
I have two C# solutions (let's say A and B). Both reference a common C# library, which is included in both solutions as a project reference. This project itself references (as a project, not DLL) another library (managed C++) which is ALSO referenced by the two top-level solutions.
Whenever one project builds successfully, the other says that the C++ library has changed and needs to be reloaded. When I do so, the C# library reference complains that it can't resolve a namespace from the C++ library. If I delete and re-add the reference to the C++ library in the C# library, the solution builds fine, but now the OTHER solution will have the same problem, and so on.
What am I doing wrong? I believe I should be able to have this sort of reference setup without problems.
Right click the Solution and select Properties. Then select '...Project Build Order'. I assume we want the C++ project to build first?
Check the Solution Properties/Common
Properties/Project Dependencies and
make sure all the Depends On are set
right.
Is there a possibility to move all the C++ project references to the common C# library? That way project A and B just need to reference the common project.