In my project I created a Plugins folder (named it "Plugins", of course) and in it I have three plugins that get imported from my c++ project. Every time I hit build content I have my dlls show up into the "Plugins" folder.
The things is that I get a DllNotFoundExeption every time I run the game and it points to two out of my three plugins. Me and my teammates found online that you can solve this by placing the dlls in the the Assets folder. We did so, and as luck would have it, that solved it, by moving the two dlls that were giving us the error it solved it. We left the one dlls that was fine where it was inside the Plugins folder.
But something was nagging at the back of my head that this would not solve our entire issue, and I was right. When w build the game and create our executable only one dll gets built, which is the only one that is within the Plugins folder.
My question is: how do I fix my other two dlls so I don't get that DllNotFoundExeption error?
UPDATED REPORT I found that the one dll that works is done in C# while the other two that don't seem to work inside the Plugins folder are made in C++.
So my new question is how do I get Unity to accept those two dlls within the Plugins folder, or is that not possible for c++ plugins?
Note that normally C++ Native Plugins are for Unity Pro only. That aside, there are some other ways to get it to work without a pro license as shown here.
Related
I had some unusual errors on a relatively small Unity project with six c# scripts written in Visual Studio. It was all working fine, and I came back to it after the weekend. Upon opening, there were 18 new errors which were preventing the code from compiling and I spent several hours trying to figure out what was going on.
The main errors were saying things like Type or namespace name 'GUIColorOverride' could not be found and associated script cannot be loaded, assign a valid script, even though they were linked and I could see the scripts had no errors in Visual Studio. I even did a full Unity uninstall and rebooted, then a clean install. This didn't fix it.
I tried a number of other things such as backing up the scripts from the assets folder and then deleting them. Opening the project and pasting them back in as 'clean' new scripts. This didn't work. I am using Unity's Cloud Collab so was even able to use this to go back to earlier pushes of the project (which had all worked). Nope.
Solved it! The issue was that the local Projects folder I had been using was connected to Google Backup and Sync. This messed with some of the files in some of the folders in PackageCache in Particular in the MyProject > Library > PackageCache > com.unity.timeline#1.2.13 > Editor > directory.
[FIX] To fix and prevent this from happening in future, I turned off Google Backup and Sync for my Unity Project(s), and am now exclusively using Unity Collab and Git. Using the specific errors that were showing in the Unity console, I located the exact path of the Unity-created files that were causing these errors in my broken project, and replaced them with the same files from a working project. This fixed all of the errors. There must have been some corrupted or partially synced files in these folders which caused Unity to have a tantrum. Hope that helps someone!
You should exclude these from the Backup!
Basically you can exclude anything that would also be excluded from git via e.g. this "official" .gitignore file for Unity projects.
Any file and folder listed here will be regenerated by Unity automatically and should not appear in any version control / Backup.
The entire Library folder in particular is part of it since its content changes quite rapidly and is recompiled every time you change a script, install/remove a package etc.
Checkout Unity Manual - Behind the Scenes for more information in detail
When backing up a project, or adding a project to a Version Control Repository, you should include the main Unity project folder, containing both the Assets
and ProjectSettings folders. All the information in these folders is crucial to the way Unity works. You should omit the Library and Temp folders for backup purposes.
To solve an already present issue with the Library folder you can most of the times fix it by simply closing Unity, deleting the entire Library folder via your file browser and opnening Unity again → Unity will rebuild the Library
I am trying to use Mono.Data.Sqlite in my Assembly-CSharp-firstpass project. In MonoDevellop, I right click on the project, edit references, and add Mono.Data.Sqlite to the references. If I build from Mono, everything goes smoothly and and no errors are produced.
When I move back to Unity3D, I always get the error saying that Mono.Data.Sqlite cannot be found. If I then close Unity + Mono and reopen both, the reference to Mono.Data.Sqlite is gone!
Anyone know what is going on?
So after further Googling and Doc reading:
Unity3D rebuilds the project files every time something changes in the Scene/Assets. This means that the added references were being reset and they couldn't be found by Unity.
The solution is to find the needed DLLs (Mono.Data.Sqlite in my case) and copy them to the Asset folder of the project.
If you want access to the DLLs you'll want to put them into a folder called "Plugins" in your Assets folder - Plugins are loaded first, so dotnet assemblies in plugins will be avaiable to you when you want to write code against them.
I have a big project with many subprojects.
(as mentioned in the drawing)
Both WebSiteA and WebSiteB has referenced to both DLL projects.
however when I change the dll's - I need to update each bin in each webSite.
I Don't want that.
I know I can put them in GAC but I was told not to (don't ask me why please.)
Is there any solution like :
so when I update any dll - I put it only at one place ? (and so the dll's won't be at each site's bin)
You can make a trick with the .refresh file reference, but not tested on the live server.
First place your common dll, on a common directory.
Second on each bin, place the *.refresh file together with the dll, that says inside from where to update the dll if a new version is found.
and so you have inside the Bins something like:
mySuperModule.dll
mySuperModule.dll.refresh
and inside the mySuperModule.dll.refresh the location of the module that need to check for update ->
d:\Dlls\mySuperModule.dll
where d:\dlls are the common place for the dlls that search for new updates.
At the end you only update the common directory dlls, and you left the projects make the rest automatic.
The whole point of the GAC is to provide that functionality, if you don't use that then you can't share the DLLs in the way you want. This is due to how sites are secured and separated from each other.
I am working on a C# application which I have divided it to few projects. Recently when the solution becomes larger, I get different errors such as MissingMethodException or even worse, DLL not found messages.
The only solution is to delete my bin folder and build the project again.
I wonder if this is a common problem with visual studio or might be I am doing something wrong?
UPDATE:
I am working on a winforms soloution, while one project is the form and other projects are user control, data models and etc.
I do reference the needed project in other projects using the visual studio's add reference option.
UPDATE 2
I am suspecting when I have a new .cs file to extend a class using partial keyword in any projects this happens!!!! I am 99% sure, I am going to check some more times to see of this is really the case!
It's not really a common problem but messy things can happen some times on visual studio.
What I would do is to check the settings and dependencies of every project and check things like they build in the correct order, platform, output path, etc. In our case, some times when the solution travels to many developers/computer settings can alter.
Also another thing you could do would be to copy the main project to a new solution and add the rest of the projects. This has worked form me in a similar situation.
I hope I gave you some ideas.
Since the suggested way of storing plugins in MS CRM is via the CRM database, I figured it's about time to do something about the method I'm currently using, which is storing the DLLs on the disk.
The trouble however is that I don't know how to embed all the other various bits that are needed by the DLL: the localization resource files (which are kept in another folder) and some referenced DLLs from the latest SDK (which had to be manually placed in the bin\assembly folder). At this point, I'm not even entirely sure this is possible.
So far I've tried to solve the localization problem by changing the build action on the resource files to "Content" or "Resource" and tested this solution (still keeping the location on-disk, but without the added localization folder). This didn't work: when I purposely generated a validation error in one of the plugins, I got the default language message (English) despite having a different language selected in the CRM.
I've faced a similar problem when trying to add some of the referenced DLL files (namely the new SDK DLLs: xrm.portal, xrm.portal.files and xrm.client). When I tried to store the plugin in the database (skipping for a moment the localization issue), I got a CRM error saying it cannot find the XRM.Client assembly or one of it's dependencies. I know I could use ILMerge to put the whole thing together, but I've got a gut feeling telling me this isn't really a good idea.
Any hints or suggestions on this issue would be great.
We always ILMerge our plugins and have had no issues with that. We don't merge in the SDK dlls, because those will already be GACed on the target server.
We don't really do localization inside our plugin dlls, though, so I think what you may have to do is, if your current resource manager is file based, to make it assembly based and just load up the necessary resources from that.
I have a set of helpers that are bundled in an external assembly that I use for most of my implementations. I will deploy this to the bin folder and leave it at that. I've never tried ILMerge myself, but it seems like an interesting concept.
Simply drop the DLLs in the folder CRMWeb\Bin