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!
Related
I need to build three completely different flavors or targets for my C#/XAML UWP app. Each of them will get placed in the Windows Store using a different name and will have different branding on it. Essentially, I produce three apps that have very similar features but need to be three different apps for business reasons. There is almost zero difference in the source code for these variations.
In Visual Studio, I created three folders and each contains the icons, manifest, certificate files, etc., for the target apps. I use a pre-build event to detect the configuration that I selected for the build and copy the appropriate files to the root of the project. Note that instead of "release" and "debug" builds, I have "release1", "release2", etc. and my configuration folders use matching names.
This all worked great with Visual Studio pre-2019! When I first set things up this way, it worked and was the easiest way I could find.
Visual Studio 2019 validates the element in the project file and my build process no longer works. If I make this empty, something during the build process sets it. I think it gets set when I create app packages for the store and is otherwise untouched.
What is the better way to build multiple targets or flavors of the app? Alternatively, how can I avoid this problem (and it's a problem since that value doesn't actually help me anywhere!)
So far, I have the way I do it now and I've also considered creating separate projects for each flavor with each project using all of the code from a shared project. In fact, I have a shared project that contains code that was once shared with the Windows Phone app that was part of the same solution. I just don't know if that multiple-project solution will work or not and it's hard to justify to the boss the day or two it might take to change the project structure.
I am using Visual Studio 2008
I have two applications (AppA and AppB) that I what to be installed using one msi-installer.
Both applications have reference AppC.
This is what I did:
I created Setup Project
I created two subfolders inside of Application Folder (AppA and AppB)
I added Project Output for AppA into related subfolder
I added Project Output for AppB into related subfolder
Problem: AppC did not appear in subfolder for AppB. It looks like dependency can only appear once.
Could please tell me how to resolve this?
You should be adding "Primary Output from AppC" specifically to each of the application folders. This version of VS Setup does not appear to detect that the same dependency needs to be included in two application folders.
There are a lot of recorded problems with the VS Setup and Deployment project, especially in regards to dependency detection. Also consider that MS has stopped shipping this project type, and has chosen the ISLE as its replacement (I would recommend using WIX instead - its free and is a more modern toolset when compared to Flexera's offerings).
A merge module is overkill for a single assembly. If you had a package of assemblies that need things like COM exposure or other group behavior things that you dont want to repeat (and possibly get wrong), then a merge module is more appropriate.
I have a windows phone 8.0 plugin created for an app. This app worked perfectly fine in Unity 4.5. I recently updated my Unity to 5.0. I also saw all the needed alterations.
Initially, we needed to create two plugin dlls. One actual and one empty simply like an interface for the editor. This went pretty well in unity 4.5
Now i open the same app in Unity 5.0 by upgrading it. and i am unable to build it for wp8 anymore. I set the inspector platforms correctly to WP8 player for my plugin dll.
But, i keep getting errors like ::
1. Plugins are colliding.
2. There are errors in the script (which are actually not)
3. Cannot load classes from module.
4.System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded.
etc.
Can anybody help me? I have tried several things already but none seems to work.
I tried :
1. Reimporting everything
2. Rebuilding the dlls.
3. Removing the empty interfaced dll for editor
4. Changing the folder structure for plugins. (Default being
Assets/Plugins/WP8)
I am stuck here since two days now.
Well, it's too late to reply. But anybody else stuck in same problem may get help.
One should know that WP8 Plugins are based on real and fake dlls in order to work in Unity Editor.
In Unity 5, you can specify platform to dll, irrespective of folder structures. However if you put dll in Assets->Plugins->WP8. Unity will mark it as WP8 dll.
Solution is,
1- Put Fake dll in Assets->Plugins->AnyFolder->plugin.dll, where any AnyFolder is other than WP8 folder. Mark it as Editor instead of Any Platform (from inspector [Select platform for plugins]).
2- Put Original dll in Assets->Plugins->WP8->plugin.dll, mark it as WP8Player
3- Keeping original dll selected, in Platfrom Settings [Inspector] modify settings like, CPU -> Any CPU, check mark on Don't Process, Select placeholder.
Placeholder drop down would show the path of fake dll, just set it.
Now you are all done :)
You must set the editor DLLs to "Editor" instead of "Any Platform" and the WP8 plugins to "WP8Player" in the plugin settings.
The project that I'm currently working on is being developed by multiple teams where each team is responsible for different part of the project. They all have set up their own C# projects and solutions with configuration settings specific to their own needs. However, now we need to create another, global solution, which will combine and build all projects into the same output directory.
The problem that I have encountered though, is that I have found only one way to make all projects build into the same output directory - I need to modify configurations for all of them. That is what we would like to avoid. We would prefer that all these projects had no knowledge about this "global" solution. Each team must retain possibility to work just with their own sub-solution.
One possible workaround is to create a special configuration for all projects just for this "global" solution, but that could create extra problems since now you have to constantly sync this configuration settings with the regular one, used by that specific team. Last thing we want to do is to spend hours trying to figure out why something doesn't work when building under global solution just because of some check box that developers have checked in their configuration, but forgot to do so in the global configuration.
So, to simplify, we need some sort of output directory setting or post build event that would only be present when building from that global, all-inclusive solution. Is there any way to achieve this without changing something in projects configurations?
Update 1
Some extra details I guess I need to mention:
We need this global solution to be as close as possible to what the end user gets when he installs our application, since we intend to use it for debugging of the entire application when we need to figure out which part of the application isn't working before sending this bug to the team working on that part.
This means that when building under global solution, the output directory hierarchy should be the same as it would be in Program Files after installation, so that if, for example, we have Program Files/MyApplication/Addins folder which contains all the addins developed by different teams, we need the global solution to copy the binaries from addins projects and place them in the output directory accordingly.
The thing is, the team developing an addin doesn't necessary know that it is an addin and that it should be placed in that folder, so they cannot change their relative output directory to be build/bin/Debug/Addins.
The key here is that team is responsible for a deliverable. That deliverable is a collection of binaries. So the "global" solution ... or "product that uses the deliverables from teams" is interested in ensuring that all of the 'current deliverables' work together. That is, that you have a deliverable from the collaborative effort.
So this begs a few questions. Do the team deliver what they consider to be a 'release'. This may be automatic in the build system. If it builds and all tests pass then publish it.
What you are looking for is a team publishing or promoting a release. The source code is how you got there, the binaries are the result. Each team controls what binaries it considers to be a release (this may be automated by the build system).
Not exactly what you asked, but I hope it is the answer that leads to the right questions to give good results.
One very simple way would be to create the solution. Include all the projects and add a project (or more) to handle the global solution build tasks. The projects in the global solution should then have a reference to the projects they need and then let Visual Studio handle how to get the binaries from each project. They will (under normal circumstances) be copied to the output folder of the build project. So the project added specifically for the global build tasks would have a copy of all the referenced projects
Another way would be to create a global MSBuild script that references the rest of the build scripts. Each project is on it's own a MSBuild script
EDIT
From the comments it would seem that there are two categories of projects. One that needs building and one that does not.
For those that need building reference them as projects in the aggregating project for those that do not require building add them either as references or add the dll as resources.
Using the later change the property of the Build action to None and copy to output directory to Copy if newer
In both cases you now have all dll's in the output directory you can then have a post build action on the aggregating project moving the dlls that should be in a specific folder (ie not in the output folder)
Have a look at the practice of Continuous Integration and the usage of a Build Server with scripted builds. This is an indispensable instrument when developing different parts of an application as a team, and your problems are a great illustration of the reason why.
You've not mentioned if you use a Version Control system. I've found in practise that each developer maintains his/hers/their teams configuration and builds locally on there machine, since you don't check *.suo or *.user files most of the personal configuration only affects the individual team member.
On a completely seperate machine check-out the same code from all repositories and compile the project on the build machine (this can be completely automated). This maintains your build servers independance.
Don't worry about it being a "Solution". You can easily build multiple solutions one after the other.
Since the output path is relative (and probably "bin\Debug") it'll get built wherever you check it out to. If you want all the binaries in the same output folder you could tweak the output path on every configuration to match. Something like "....\bin\Debug" (obviously this affects where the projects get built to on the local machines but it might not matter). That way multiple projects would get built the same target output.
You could also include a seperate setup build on the build server which isn't on each developers local machine to package up the final product.
There are 5 console apps working off each other's outputs and are separately installed on my computer (C# 4.0, I am the author) . Management would like to distribute this suite of apps to other users, but aren't thrilled about asking non-tech users to install/configure 5 separate applications. Is there any way I can compile each program down into a .dll and reference them through a single master application?
Q. The main issue seems to be that you don't want 5 separate installation steps?
A. Make an installer for the suite :) Use any MSI builder (WiX, Visual Studio setup projects, InstallShield, and many others; Heck, you could even do an XCOPY deployment in most cases)
Q. How do I directly invoke these programs from within a single process?
A. Options:
Load the assemblies in your AppDomain.
Use a separate AppDomain in case of name(space) conflicts or version conflicts
Q. How do I optionally 'hide' the presence of the external console apps from view
A. Look at ilmerge to possibly combine the 'external' assemblies so they aren't visible anymore. If you can't use ilmerge (conflicts, or e.g. WPF apps) you might embed them as resources and load them on demand as per 1. and 2. above
Update: https://libz.codeplex.com/ is a nice looking project that makes this easy (haven't tried it myself)
Just because each of them is a separate .exe file doesn't mean you can't treat them as one application. And they don't have to be installed or configured separately either.
But a much better solution would be to rewrite each of the applications, so that they expose classes or interfaces that can be used without actually running the application. This way, communication between the parts is going to be much easier.
In .Net, the only difference between .exe and .dll is that you can run .exe directly. But you can treat both as libraries, so you can use functionality from one .exe in another .exe. Another step might be separating the core of each application into a .dll and make the .exes just deal with input and output. With this, the combined application wouldn't have all the code that it doesn't need from the other ones.
Its possible if every assembly is using different class names. Just include the whole source code when you compile the final version in one project.
Go to Project's properties, Application and change OutputType from Console to Class Library.
EDIT
Would like to express my doubts on architectual desicion like this, correct me if I'm wrong in my thinking:
Having different EXE applications standalone, I presume, you have different Applications that works standalone.
What advantage you gain by converting them in DLL's and puting them together in one master app ? Why do not just use this EXEs with one master app and launch them ?
In this way you leave as is it already working + you add a layer (master app) so for final user all this seems like one single app.
That is possible - several options:
you put the functionality of each console app into a separate class within the same project and have one "master console app" provide their functionalities
you put the functionality of each console app into a separate class each in different project with DLL as target, then you reference those DLLs as needed from your "master console app"
Note: IF you go the DLL route you could embed the DLLs into the console EXE using the technique from http://blogs.msdn.com/b/microsoft_press/archive/2010/02/03/jeffrey-richter-excerpt-2-from-clr-via-c-third-edition.aspx
With both option (all in one EXE or EXE + embedded DLLs) you can just make an XCOPY deployment if there are no other dependencies...