I have a pretty large project where different scripts are available and attached with different game objects in the hierarchy. Now I want to make dll of all files. I found unity official guide that involves lots of steps that I have to repeat for every script. Not only this but I have also attached each dll to gameobject again then, need to remove the same script whose dll i have converted. And if there any setting on the inspector i have to follow again. My question is that is this the only way to do this job? Is there any automatic way available? that convert all my scripts into dll? within unity ?
I would suggest you to split all stable and reusable code into unity packages or at least into separate folders where you can create assembly definitions files so all scripts inside won't compile every time you change something in a different place. Start here: https://docs.unity3d.com/Manual/ScriptCompilationAssemblyDefinitionFiles.html
Related
hello i wanted to know where are unity scripts stored in a build...
actually i want to give update to my game but saw that there's no proper way to do it without giving full update... assetbundles cant import executable code... so what i came up with is make an entire new application/unity project which acts like a launcher to my game and it will fetch a json from server with all filenames and latest versions and compare them to the filenames and versions on disk... then it downloads and replaces any missing or old version files from the disk with streamwriter and all... then it will call to start the actual game's exe and quit itself...
Now what the problem is that i dont know where are scripts(the custom scripts we made during development) are compiled and stored to as dll or any other files so i can look out for them because i noticed there are a lot of system(default) dll in unity build and i dont want to iterate through them every time my application checks for an update...
Edit:
it strike me sometime after... i also wanted to know if all of our scripts are compiled(and stored in a build) in one dll or whatever file or as separate dlls. cuz say if i have scripts almost extending to 50mb and if i give even a minor update, downloading the whole 50mb dll wont be worth for the update mechanism the way i vision it to be...
Please ignore my grammar. english is my second language
By default Unity compiles everything game related into the assembly: Assembly-CSharp.dll
All the assemblies are located in /GAME NAME_Data/Managed/
You can however split your code up into different assemblies using Assembly Definitions.
I'm quite new to C# and Unity so have mercy on me. I'm using visual studio.
I have what seems like a pretty common problem. Which is - i want to use functions i write across several projects in unity. I don't want to have to go search for the code in some folder, copy paste it into the new project, or fiddle with symbolic links or use .dll's. These are all not great solutions to the problem. Can't i just somehow create a class I can access across all my projects? Custom namespace perhaps that is not project specific? that i can simply just call at the beginning of wherever i want to use my homemade scripts.
If you don't want to build a custom DLL and the headache that comes with maintaining its versioning alongside Unity releases, consider building an AssetPackage. You can right-click in one of your projects and export a bunch of scripts that you want to be re-used in other places together as a package. When you start a new project, just load that package into it by dragging and dropping it.
If you're using git for your projects, you could add the shared code into a separate repository and add them to your projects as a git submodule.
You have 2-3 things to consider in this situation:
Ease of deployment
Whether or not you will update that code
Ease of update, if you will update it
If you just want to bring it in once, then Erik's answer should be simple enough.
If you want to keep things as an updated library though, you will need another method.
Symbolic links as you mentioned would be the best, or DLLs. However, with this, you'd run the risk of breaking your other projects if you ever modify the common lib from inside your project.
Another option would be to have a separate VCS (git, svn, etc) inside your project for your common code. This way you can update if/when you want, you can roll-back if something breaks, and you can even fork your "common" code to make a project specific change.
Since OP mentioned it, in this case, OP could specifically use Git Submodules or simply add a second Git project and add that sub-Git to the parent's .gitignore file
I have a Unity creates solution for UWP (hololens actually, not sure if it matters).
Most of my work is done on a class library that contains my logic. I want to call from the unity C# scripts into this class library I am using. Since the Assembly-csharp DLL gets recreated completely every time, I obviously can't just add a project reference in there.
What's the best way to achieve this?
What I've found so far is that I can pull the actual DLL binary of my library DLL into the Unity Assets folder, at which point it actually does get referenced in the Assembly-csharp project - however - the DLL actually gets copied to a separate location (\Unprocessed\MyLibrary.dll). That means I need to copy my project there everytime I make a change (or re-publish from Unity which takes a bunch of time).
I know I can have a post-build stage that will copy the file - however - is there any more "correct" way? The way this works now (dropping a DLL into the Assets) also has other disadvantages such as making building a certain flavor much harder than it should be.
Thanks
That is the correct way: you put the library DLL in Unity's Asset folder, and never touch the generated C# project.
Consider that in most common scenarios, both the library itself and the Unity code referencing it would change so a rebuild of the Unity project is a natural part of the process. If that takes too much time, it is usually advisable to create a dedicated, smaller Unity project to quickly iterate through the DLL development cycles.
I need to develop a single Unity3D standalone build for separate project modules.
Consider, I have various projects related to 'Physics' for the 12th grade, which contains separate models, images and their respective functionality. For example, Project1: 'Optics', Project2: 'Electrostatics', Project3: 'Dual Nature of matter' and so on. All of these projects are independent of each other in terms of functionality and are complete on their own. Now, I create a 'Unity build'(say, for android initially) that contains a menu layout along with hyperlinks to download separate projects aforementioned from a server. The requirement is to allow the user to download a project(Say, project1: 'Optics') jar/build out of many projects available as an extension/addition to the previous 'Unity build'(even if the size of the build already installed might increase on device). As soon as the project is downloaded, the user should be able to run the project module over the 'Unity Build' instead of running a separate application. Similarly, when the user is done with the downloaded project module(Project1: 'Optics'), another project module(say,Project2 : 'Electrostatics') can be downloaded from the menu of the build which will run over the same 'Unity Build'. The 'Unity build' application serves as an interface which can add a separate layer of encryption so that the projects cannot be downloaded over and run separately by any unrestricted user. Somewhat similar to a media player which can play various kinds of video files. However, in this scenario, I need to run various project modules.
I am looking to create builds for different platforms - Android, Windows, iOS and Web browser (if possible) with similar functionality.
Any kind of help will be appreciated :)
Thanks!
There is a an "example" that comes with Unity as an install option and I believe it does exactly what you want, it has a menu where you can select different demos, where each demo is a project in itself. You should look into that.
Your question is mostly about organisation.
Sounds like your 'Unity build' is a kind of downloader with menue. May be this could be a website. Is the server a webserver?
The server has to have all projects for all possible plattforms, like a matrix.
If somebody starts to download a project, you have to choose the right build for his plattform.
To estimate the plattform, you could send a parameter with the link.
All of these points have many solutions depending on your requirements.
Good luck.
What you need are Asset Bundles.
What are they?
Compressed packages that serve as game extensions that can be downloaded and imported to a unity build at any time. With AssetBundles you can package scenes and load them into unity and load them.
How to create AssetBundles?
Basically you can select any Asset from your project and in the inspector you assign that Asset to a new AssetBundle in the inspector (at the bottom it says Create AssetBundle). A detailed section can be read here https://docs.unity3d.com/Manual/BuildingAssetBundles.html
In your case you should create many Asset Bundles with one scene in each.
How to download and load unity scene files from AssetBundles?
It could be a bit tricky but it has already been accomplished here http://forum.unity3d.com/threads/dynamically-load-scene-from-assetbundle.379316/
Common pitfall
Remember that AssetBundles aren't cross platform compatible. In other words, the Asset Bundle created is restricted only to the platform it is built for so you need to recreate your AssetBundles for each platform
Hope this helped!
There are a lot of variables and methods in my program and I want to seperate some of them in other class files. But as the program grows the methods and functions can change.
I searched on the net but many people generally speaking for dll files. Without making a dll file, how can I arrange my code and split into small class files?
Yes, just split it out in to a separate file in a new class but still inside the same project. The term for what you are doing is called Code Refactoring. There are some tools built in to Visual Studio to make it easier to do, and there are some 3rd party tools that add even more features to make it easier to do.
But all it boils down to is just making new classes in the same project and referencing those new classes from where you took the code out from.
You can add folders to your solution. Classes are by default a namespaceprovider, so that classes in this folder have a different namespace.
For example if your default-namespace is MyNameSpace and you create a folder called Entity then all classes in this folder have the namespace MyNameSpace.Entity
And all Items in a project are compiled to one single dll or exe
Just add more classes to the project and put the data and behavior (methods) into the appropriate classes. The project will still build into a single exe or dll.
Generally, it's better to add a second project under the same solution call it "CommonLib" or something like that. Then you add it as a reference to the main application and set up the project so that the applications build depends on the libraries build. Add a using statement for the common lib where ever you want to use those objects. This is definitely better for large scale or enterprise applications. There's a pretty decent chance that somewhere down the line you'll want to reuse some of this code, if everything builds into a single exe that won't be an option.