When I build/enter play mode in the Unity IDE, many warnings clutter the console window that have been generated by script compilation of 3rd-party assets. How can I disable or hide the console warnings from specific assets without making changes to those assets?
I anticipate people righteously howling about how I need to fix the warnings instead of sweeping them under the rug. But to those folks, please consider...
The code is in 3rd-party assets--not mine. Typically, no upgrade on the asset is available that would fix the messages, and I've reviewed the messages and judged them to be benign. I realize the value of warnings, but I don't want to dig into 3rd-party code to fix the warnings. I'm also reluctant to change the code in these assets because it essentially gives me a local fork. And then future updates on the asset from the 3rd-party will need to be hand-merged against my local updates. That's time-consuming and introduces risk.
Two years later, I can answer my own question. :)
Create .asmdef files such that third party assets are in one manifest, and all project code is in a separate .asmdef. So in my project, I keep the 3rd-party assets just under Assets with project one level down.
Assets (folder)
thirdPartyAssets.asmdef
...other files and folders...
Project (folder)
project.asmdef
...other files and folders
This basically "disables" warnings from 3rd-party assets by simply not building them. You will still see 3rd-party build warnings if those assets change or a clean build is made.
The original question was how to disable for specific assets, so I'll note that it's possible to arrange the .asmdefs to include/exclude assets in different groups. And simply putting an .asmdef into the folder of one asset that warning-spams, will cause that single asset's warnings not to be shown except for the cases I described in the previous paragraph.
Put the plugin into its own folder and make an assembly definition if there isn't one already.
Then you need to create a csc.rsp text file alongside the assembly definition
Edit this csc.rsp and add this line
-warn:0
This will set the warning level to 0 (no warnings) for that assembly only.
see https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-options/errors-warnings
Thank you to both Erik Hermansen and Adam B for providing solutions.
I went with Erik Hermansen's solution, but modified it slighty, sort of the other way around :) :
moved all third party stuff into a folder Assets/ThirdParty, and created Assets/ThirdParty/ThirdParty.asmdef
kept my own stuff at top level, and created Assets/MyAssembly.asmdef
Note that you probably have to add some references to each assembly:
MyAssembly.asmdef:
ThirdParty.asmf
Unity.TextMeshPro
ThirdParty.asmdef:
Unity.TextMeshPro
(maybe some others, depending on your own project)
Related
Say I bought different items in the Unity assets store, including scripts, models, animations, etc. After importing, they are all in different folders under the 'Assets' or 'Assets/Plugins' with their brand name, and each of them has its own folder structure.
Should I put what I need to my own folders or just leave them where they were originally?
Things to consider: I will make some changes of the scripts, animations, prefabs of models. And the assets I bought probably will upgrade, and I want things that I used to upgrade with it. So what is the recommended workflow to use them? Any experiences are welcomed, thank you!
Moving the plugin to a different folder won't affect future plugin upgrades, However, getting into the plugin and altering the source code or content will end up conflicting with the future version. I recommend not altering the plugins original content.
In case if you do want to override then, either you can have a wrapper script around the plugins script and customize it based on the necessity, or use version control(like git) while upgrading plugins in a separate branch and later merge your edited version of the plugin vs the latest version of the actual plugin.
Also unity these days has a well organized packages directory system, which you can refer to custom organize the external third party plugins.
Is there a way to know what is of all my GO, textures, sounds, etc, are not in use in all scenes, to delete it?
When i tested my game, I have inserted some textures, sounds, GO etc and some of them are not in use.
I'm using Unity 5.1.1.
2018 ..
The modern solution is simply ..
Click on your scene(s) and select "Select Dependencies".
It will show you what is used; the rest is unused. Really it's that easy.
As with many things in Unity pipeline, it is very common to use an asset, virtually every project uses a few well known assets. "A+ Assets Explorer" (link) is very common.
When Unity builds the executable, it does so only with required assets. Anything else that might exist in your scenes or projects is simply ignored.
This answer over on Unity Answers has more info.
There are also options available in the Asset Store, such as this one.
Asset Hunter is a tool that analyzes your buildlog and gives you an easily understandable overview over unused assets in your project folder.
The results are grouped into folders and file types, making it easy to start cleaning up your project.
I had two target for my application. One free and other is for paid.
Now i need to add different icons for both target. Now the problem is that i can not used apple naming conventions like now i use icon_free.png and icon_paid.png.
My Problem when i add 512px icon then will iOS will automatically pick the correct image for each build
There are two ways.
First option: You can use apples naming conventions. Just store the icons in different sub directories. When creating the second target one suitable sub-dir was created. However, you can create a new one.
Place the files with default names in each of the directories.
Create separated groups for them in your navigtor tree in xcode. Upon creation of the second target that should have been done anyway. So you can have both versions of the icon with the same name at different branches within your navigation tree.
Then go to the copy build settings of each target and make sure that the appropriate version is included for each target.
Second option: Alternatively give the icon (and default etc.) files different names and name them explicitely in plist.info. And plist.info then exsist for each of the targets. For plist.info xcode should have created separate files anyway. You find it on the info tab of the projedct settings close to the build obtions tab.
In general I found it is good pactice beeing neat with separate folders. After hasseling around with difficult problems when having two targets with newer apps I always have one sub-dir with all the shared resources and one for each of the targets. It makes it easier to boundle the copy and compile settings for each of the targets accordingly.
Just one more: When ever you apply changes to the bundles in this way you should delete the apps thoroughly from the simulators and test devices. If you don't then you may run into situations where the root cause is difficult to find. That is that there are old versions of some of the resources on the device. They will not be updated along with new releases. You will then have as best missing resoures on 3rd party devices and in the worst case you will chase errors and all what you try does not have an effect on the device/simulator because the locally existing resource is not being updated. Difficult to figure out.
When you add a nuget package to a project it puts the assemblies in a /packages folder at the solution level.
I know that there are ways to change this, but I'm wondering why this is the default location, as it seems very unhelpful for these reasons:
1) If you have a project that is part of multiple solutions, the /packages folder won't necessarily be where you the project expects it.
2) You are expected to manually check it into source control for other team members, which is much less convenient than if it was part of the project that needs it.
3) If you move the project somewhere else on the file system or to a different machine that doesn't have the full code base, it won't find the /packages folder where it expects to.
It seems all of these would be resolved if NuGet just used a /packages folder inside the project, not the solution. And that seems like a much more logical place to put packages that the project relies on anyway.
So... I'm assuming that there were/are some good reasons for doing it at the solution level, and I'm hoping someone can enlighten me.
You should have a read at this, that explains how to use nuget without commiting packages to your source control, and by side effect solve points 1 and 3 of your question : http://blog.davidebbo.com/2011/03/using-nuget-without-committing-packages.html
I think it's to save disk space. If you had a large solution with 50 projects and you used a package in every one of those, you would end up with 50 copies of that package, binaries and all. Whereas keeping them at solution level is far more efficient in that respect.
In terms of source control, you shouldn't be putting your actual packages folder in there. Just add the packages.config file and either do what David Ebbo suggests in the blog post mentioned by mathieu or create a simple batch file to download all your packages based on the packages.config files it can find.
It's not much effort to create your own company nuget feed, so you can keep your private packages in there.
I have 2 projects and I want to use in the first project, a class (i.e. view controller) of the second. Instead of importing all the files of the second project in the first one, is there a way to link it like a framework or library?
I tried the following unsuccessfully:
Dragged-dropped SecondProject.xcodeproj and checked SecondProject.app as a target
Added it as a dependency project in the first project dependencies
Pointed to the header files by adding in the "Header Search Paths" a path pointing to the second project which I copied in a subfolder of the first project.
When I include "SecondProjectViewController.h" I get no errors but when I try to instantiate it I get the "OBJ C referenced from" error.
Any help is deeply needed and appreciated! =)
F.
As an experienced developer I would suggest not sharing code this way across projects. The simple reason is that changes in one project will then directly effect other projects, often rendering them un-compilable. For example, if you share a controller class and decide to implement a change with a new import, then any project that uses that class will be broken until you open then in xcode and ensure that the imported class is available.
A better method is to compile your first project as a static library or framework. I'd also recommend ensuring that it is version some way. For example, in my projects I create static frameworks and store them in a directory called "v0.0.1", "v0.0.2" etc.
The framework can then be dragged and dropped into a second project to use it. The second project then refers to it via the directory path. The advantage of doing this is that if I then change the first project, the second one if not effected by the changes until I choose to update the frameworks path.
Sharing files between projects will work for small cases, that being 2 or 4 projects, but once you have more than that it rapidly becomes un-manageable.
You have only a few steps to go:
4) in First project, click the disclosure triangle in the Groups and Files section for the Second Project reference. this will display the targets of Second Project.
5) Drag the target reference (e.g., static library) from Second Project to the target in First Project's link phase.
That should clear up all the linker errors for the symbols which exist in Second Project's library. Of course, you'll have to remove those sources (based in second Second) which are compiled and linked from First.
Managing static libraries for huge codebases is dead easy this way (although I prefer the build up to the minute (as well as several build variants), and don't reference archived binaries as Derek does). Learning to minimize changes which break builds takes time to learn. dynamic libraries are a bit different - depending on their distribution, you may want to version (as Derek outlined). It's good to share, but you should put the shared exported symbols in a library, which is a dependency of both apps. Just be careful not to add too much unnecessary objc symbols to the library - objc symbols and their references cannot be stripped from the final executable and they will cause runtime collisions if they appear in two images (dylib, app, static lib) within the same process.
You can add the view controller's files to your 1st project regardless of where they are on disk -- the project will make a reference to their location.