unity scripts location after build - c#

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.

Related

Convert all C# scripts to dll in unity project automatically

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

Easiest way to use a managed library in Unity3d that's part of the solution

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.

Linking Modules into Small Footprint Assemby

According to http://blogs.msdn.com/b/junfeng/archive/2005/02/12/371683.aspx I should be able to create a single .exe file build from some source code and a .netmodule file. However, after looking at http://msdn.microsoft.com/en-us/library/92b5ab4h.aspx and http://msdn.microsoft.com/en-us/library/k669k83h.aspx I cannot seem to make this happen. Whenever I run my .exe it is looking for the .netmodule externally.
Does anyone know of any example showing which options I have to pass to csc to make this do what I want?
For example I have, common.netmodule and program.cs, and I want a single file program.exe that has common.netmodule in the assembly.
After rethinking things, I decided to solve the problem at the source code level. Instead of compiling a common.netmodule file, I just have Maven copy my common.cs file into the project specific directories, and then compile. It works, it's simple, and I cannot believe I wasted so much time trying to figure out the abstruse details of .Net assemblies.

Additional global include directory in Visual Studio for C#

There are a lot of little things I find myself re-writing here and there because they might be too large/complex to represent as a snippet, but realistically it doesn't make sense to make a stand-alone DLL out of it because we might only be talking a few dozen or a few hundred lines of code.
For example a little form which contains only a text box where the user enters a password and closes on {Enter}.
Or an extension method which can serialise/deserialise any object to/from a GZipped file assuming the object is marked as Serializable.
The list goes on. I have accumulated lots of little bits and pieces over the years and it's not organised in any neat way.
In C++ projects, I can write a lib file containing these bits of code which I can add to my compiler settings in such a way that any future C++ project I create has this lib included. I have done this with ATL and Boost.
I don't know of a way to do this for C# projects. Is it possible?
Edit:
If I make an assembly, I have to compile it to a DLL and distribute the DLL alongside my main executable. The DLL may be small or it may be quite large, I don't know. But I may only need to use a few tiny functions in that DLL for my project. In C++, only the functions I use are statically linked when I use the library, however if I distribute my software with a DLL then I have to distribute everything.
I know it is possible to merge the DLL with the main executable so that the user isn't aware that there is a separate library, however the whole DLL is still being packaged along with the executable.
Imagine I write a DLL with lots of my own maths, stats, file IO, image manipulation, serialisation, user IO, etc included. Nothing fancy, just some common things I find myself doing quite frequently. The DLL might be, say, 4MB.
Now I want to write a program which uses a tiny part of the DLL, and if I were to simply copy/paste the necessary code then my EXE would end up being, say, 700kB.
Are you saying that I either copy/paste the code I need, or I have to distribute a 4MB DLL along with my 700kB EXE?
Aside from using an assembly, the only way I know of is to create a link in your project to the source code in question. In visual studio the process is:
Project β†’ Add β†’ Existing File β†’ Add As Link (the little down arrow:)
It is not possible at a source code level, although often requested (just Google c# #include equivalent). The only reasonable alternative that c# offers is compiling your common code as a DLL and adding a reference to it.
Note that although you can add a file to your project from another project, it will take a copy and therefore not maintain updates. I have used this to achieve the same effect 'manually' - when the common file is updated, I excluded it from the project 'referencing' it and then re-added to get a fresh copy.
UPDATE As commented below, you can add as a link - how cool! Why did nobody tell me.
We add a common directory to the overall includes path, then use
#include <somefile.cpp>
directly in our cpp files. It'll include the source straight in.

C# DLL Wrapper Concrete way

I got many .dll files for my project.
It is quite troublesome that moving a lot of .dll around for a project.
Is there any simple method to group many .dll file into one?
I heard something call dll wrapper but I cannot find out any concrete method related to it.
Can anyone give me a hand please.
Thank you very much.
By the way, all my .dll files and project are written in C#.
You can use ILMerge utility
ILMerge is a utility for merging multiple .NET assemblies into a single .NET assembly.
It is quite troublesome that moving a lot of .dll around for a project.
Really? Define many. I have projects consolidating 50ΓΌ+ dll#s and you know what - it is trivial to move them. Scripts, installers all do that automatically. Including configuring a dozen build server agents with the necessary copies etc.
Really, the only time I have to copy thm around is when I deploy manually to another machine for hotfixing or manual testing. I do that quite a lot at the moment (develop local, copy / paste the folder content to another machine to run tests - faster and closer to the database). Trivial. if it gets more work, I put in a little script. Trivial again.
Being a programmer is not about just knowing how to write some small classes, it also involves optimizting your environment a little. In times of CI (Continuous integration) and pretty much mandatory installers knowing more than just your programming langauge is a must. And then this is trivial.
You could unite your DLLs into a single multi-module assembly, or just create one giant C# project that includes all the DLL source files and compiles everything into a single DLL.
However, what's the problem with moving several DLLs around?

Categories