I have added Assembly Definition (.asmdef) to my script folder (my custom unity scripts). Now Unity complains that it cannot find OVRInput class which I've used it in one of my scripts (GameManager.cs):
This OVRInput class is compiled into Assembly-CSharp.dll managed assembly as seen below:
I expect Unity, by default, to see this dependency and resolve it but somehow it doesn't. So I decided to manually add "Assembly-CSharp.dll" to the dependency section (called "Assembly Definition References") of my assembly but Unity gives error that it cannot find such an assembly.
The following is my custom Assembly Definition File (that puts all of scripts in "Scripts" folder into the assembly):
Target platform: Android (Oculus Gear VR)
Unity version 2018.3.13f1.
That's kind of the point
Assembly definitions are (effectively) entirely separate projects (part of the same solution, but separate dlls). This is in fact how they are displayed inside Visual Studio's Solution Explorer.
They're meant to be things you reference in to (like TextMeshPro or JsonDotNet) not out of. As such you cannot reference the main Assembly-Csharp "name space."
The advantage is that when a script file changes only its containing assembly is recompiled, instead of the entire project.
In this case, if you want to reference the Oculus files, you either need to create another assembly definition containing those files (and add it as a dependency of your first assembly) or not use an assembly definition at all.
Related
When I try to build my game, Unity includes the scripts contained in my Editor directories. This implies the build to fail because Unity.Editor is not accessible during the build. I'm using Unity 2020.1.6f1, how can I solve this problem ?
This is the type of error i'm getting durring the build:
Assets\Scripts\Editor\EnemyLootEditor.cs(7,32): error CS0246: The type
or namespace name 'Editor' could not be found (are you missing a using
directive or an assembly reference?)
Theses errors doesn't occur when the game is lauched in Editor Mode.
This is a picture of my Scripts folder that contains all of my code files, including my Editor files:
As #Thomas says, yes, you have to check that your Editor files are stored in the Editor directory, and use the compiler directive when you use them.
BUT this problem seems more related with Assembly Definition files, check this related link.
Are you using assembly definition files? They don't respect Editor
folders. You need to add Editor asmdefs.
Summarizing, if you have one .asmdef file in your project, and you are using Editor scripts, you need to ALSO have a .asmdef file for your Editor scripts.
Files stored in a folder named "Editor" do not included in builds. (see special folder names in unity)
If you make calls to editor code in "regular" script files you have to surround this code with the UNITY_EDITOR compiler directive:
#if UNITY_EDITOR
// will not be present in build
[...]
#endif
I am trying to compile several scripts in my project into an easier to move and manage DLL file, however several scripts call UnityEngine.UI, and I know that the DLL file used to exist in /Contents/UnityExtensions/Unity/GUISystem/Editor/UnityEditor.UI.dll however the only data I can find for it now are the uncompiled files inside the Package Manager, where is the compiled DLL stored now?
The simplest answer that I just found is to look in the project folder of one of your projects in Library\ScriptAssemblies
I have a project with a runtime text template, i want to be able to call
mytemplate.TransformCode();
from a different project. I only need access to the mytemplate.cs file it generates and do not want to edit the template in the second project.
I have included the .tt file in the nuget package of the first project and installed the nuget package on the second.
The problem is the actual .tt file is installed into the second project, and then fails to compile due to the assembly reference
<## assembly name="$(SolutionDir)\..\..\bin\LanguageExt.Core.dll" #>
Because they relative path to the assembly is no longer correct.
So I need a way to either suppress installation of the tt file into the second project, and be able to instantiate the mytemplate class file from the dll and call GenerateText()
If that's not possible I'd like to at least be able to use a parameter for the assembly relative path, so I can make sure it builds in both places.
Any ideas?
Right, it's as simple as setting 'Build Action' to 'None' on the tt file
gets coat
I added a reference itextsharp.dll to my plugins project, when running my plugins using plugin-registration tool I get this exception:
Could not load file or assembly or one of its dependencies. The system
cannot find the file specified
I tried removing the ref and adding it again, cleaning and then adding it to my project from different places.
Is there restrictions in plugin registration tool about adding non crm dlls? why ? how to solve it?
This is not going to work - you cannot reference external assemblies from CRM plugins that are registered in database. If you want to do this, you will have to merge your external dll with your plugin assembly. You have to remember that adding assembly as reference is not automatically making your referenced assembly available for your base assembly, therefore if you register your plugin assembly in CRM, system is not going to "magically" find somewhere your external assembly (in your case - "itextsharp.dll"). If this is not Online system, you can add your assembly to GAC, or register all your assemblies on Disk instead of database (not recommended approach). If you want to register them in database, you will have to merge everything in one assembly using ILMerge for example.
You can't reference something in a plugin unless it's in the bin of the CRM.
To make it work you need to ILmerge your reference with the plugin. Install this package in your project: MSBuild.ILMerge.Task. Then build. It will work instantly. The package will merge everything in the bin after the build. So make sure every other references are marked "Copy Local = false". Otherwise, you'll have a crazy big assembly.
Finally, Microsoft released a solution for this. You can build a nupgk file and register dependent assemblies.
Here are the white paper and my post about this;
Microsoft : Microsoft White Paper
My summary: Here is the link
I have a VSTO addin, which works fine. I am trying to give it a plugin-loading mechanism so that others can add plugins to my plugin. I sounds horrific, I know, but it seems to best option for now.
I publish my addin to a folder called 'Published'. This creates the application manifest (Symbols.application) and also a folder called Symbols_x.y.xx.yy with the actual addin assemblies in it. Visual Studio increments this version number each time I publish, so the assemblies are never in the same place twice.
The plugins are in a folder Published\Plugins. I load the plugin assemblies using Assembly.LoadFile(string) and this works OK. The plugins are all in folder which stays in the same place no matter how many times I publish it and I can scan that folder for DLLs and load them.
What doesn't work is when those plugin DLLs have dependencies. In particular, one depends on a COM object. Visual Studio builds an automatic Interop DLL which it puts in the Published\Plugins folder, alongside the corresponding plugin DLL. An exception is thrown as soon as any attempt is made to access the COM object, saying that the interop assembly could not be found.
Putting the interop DLL into the folder Published\Symbols_x.y.xx.yy folder works, but that requires manually putting it there each time. I've tried adding the plugins to the AppDomain's PrivateBinPath, but the documentation says that anything outside the ApplicationBase will be ignored and it seems this is indeed the case - it doesn't work. ApplicationBase is set to Published\Symbols_x.y.xx.yy.
It seems to me I have four options:
Figure out how to change the ApplicationBase, moving it up one level, and then add the Published\Plugins folder to the AppDomain's PrivateBinPath.
Make some change to the application manifest to indicate that assemblies can be loaded automatically from Published\Plugins.
Find some other way of explicitly loading an assembly into the AppDomain, not just into memory using Assembly.LoadFile.
Anything else anyone wants to suggest!
But I can't find any way to get any of these options to work. Help!
The solution was provided by the MSDN forums:
I've added an event handler to AppDomain.CurrentDomain.AssemblyResolve. This gives you a chance to load the assembly in whatever way you like, including by loading it from my plugins directory.