Upgrading Old Unity Code to Unity 5

Upgrading old Unity code to Unity 5

what did i do wrong or did unity change it?

Unity changed. I've seen similar questions for the past few weeks. Although I don't think they are duplicates but it would make sense to answer all these here for future questions.

The animation variable is defined under Component as a public variable which MonoBehaviour inherits from. Your code then inherits from MonoBehaviour and you have access to animation.

These are the complete list of variables from the Component class that are deprecated:

public Component animation { get; }
public Component audio { get; }
public Component camera { get; }
public Component collider { get; }
public Component collider2D { get; }
public Component constantForce { get; }
public Component guiElement { get; }
public Component guiText { get; }
public Component guiTexture { get; }
public Component hingeJoint { get; }
public Component light { get; }
public Component networkView { get; }
public Component particleEmitter { get; 
public Component particleSystem { get; }
public Component renderer { get; }
public Component rigidbody { get; }
public Component rigidbody2D { get; }

New way to access component that attached to the-same script:

Use GetComponent<ComponentName>(). Capitalize the first letter of that variable to make it its component class. One exception is audio which becomes
AudioSource instead of Audio.

1.animation.Play("Cube|moving side"); becomes GetComponent<Animation>().Play("Cube|moving side");

2.rigidbody2D.velocity becomes GetComponent<Rigidbody2D>().velocity

3.rigidbody.velocity becomes GetComponent<Rigidbody>().velocity

4.renderer.material becomes GetComponent<Renderer>().material

5.particleSystem.Play() becomes GetComponent<ParticleSystem>().Play()

6.collider2D.bounds becomes GetComponent<Collider2D>().bounds

7.collider.bounds becomes GetComponent<Collider>().bounds

8.audio.Play("shoot"); becomes GetComponent<AudioSource>().Play("shoot");

9.camera.depth becomes GetComponent<Camera>().depth

I don't have to put all of them because the example below should guide anyone do this. These are the most asked and asked components on SO.

Cache Component:

You can cache component so that you don't have be GetComponent everytime.

Animation myAnimation;
void Start()
{
    //Cache animation component
    myAnimation = GetComponent<Animation>();
}

void Update()
{
    if(somethingHappens)
    {
        //No GetComponent call required again
        myAnimation.Play("Cube|moving side");
    }
}

Upgrading Unity to 5.11

I recently had the same issue trying to update AutoMoq-Unity5 to Unity 5.11.

Comparing the current version of BuilderContext.cs with the earlier 5.9 version I saw the change was

From

[DebuggerDisplay("Resolving: {OriginalBuildKey.Type},  Name: {OriginalBuildKey.Name}")]
    public class BuilderContext : IBuilderContext

To

    [DebuggerDisplay("Resolving: {Type},  Name: {Name}")]
    public struct BuilderContext : IResolveContext

So as you mentioned I changed my code from

        public override void PreBuildUp(IBuilderContext context)
        {

To use the BuilderContext by reference

        public override void PreBuildUp(ref BuilderContext context)
        {

And where I used OriginalBuildKey.Type I now have changed from

        private static Type GetTheTypeFromTheBuilderContext(IBuilderContext context)
        {
            return (context.OriginalBuildKey).Type;
        }

to

        private static Type GetTheTypeFromTheBuilderContext(IResolveContext context)
        {
            return context.Type;
        }

My unit tests are passing at that.

Project fails to build after upgrading version of Unity

Project in question is on hold. I started a new project in Unity 2019 and this issue remained. Therefore I was aware this wasn't a project issue but more environmental.

After looking across the internet I discovered this thread:
https://forum.unity.com/threads/error-building-project-with-visual-studio-in-unity-2018-unity-package-source-file-not-found-error.530766/

Upgrading to the latest version of Visual Studio 2017 has resolved the issue. Although judging from the thread above, upgrading to 2017 15.9.5 resolved the issue for a lot of people.

Manually adding .NET 4.5 scripts to Unity: Potential issues?

SHORT ANSWER:

Install the Visual Studio Tools for Unity (it should automatically get installed when you install Unity), when you do you can tell your .csproj in the "target framework" drop-down to target the special version of .NET Unity uses and you will only be able to compile dll's that have methods and types that Unity supports.

---

LONG ANSWER:

It is because Unity does not use the installed version of .NET on your computer. Unity uses Mono, and a very old version at that. This allows unity to be ran on multiple platforms and OSes. Because of that you can only use features that are in the supported version of Mono.

However, if you look at their roadmap the alpha build you will see

Scripting: C# Compiler Upgrade
Upgrade Mono C# compiler against our
current .Net 2.0 and 2.0 Subset profiles. Note that this is an upgrade
of the C# compiler only, not the full Mono runtime

Then further on in the "research" phase

Scripting: .NET Profile Upgrade
Upgrade .Net profile to 4.6 enabling access to the latest .Net functionality and APIs.

---

UPDATE:

You can get a experimental build that uses the 4.6 profile from the stickied post here.

Here are the notes for the 5.6.0b5 beta release

• For this release, the Editor and the following players should be working:
  
  
  • Windows, OSX, Linux standalone
  • iOS with IL2CPP
  • Android with IL2CPP and Mono
• Other platforms are known to not work yet, and are probably not worth installing.
• Managed debugging via Visual Studio Tools for Unity or MonoDevelop is not supported in this release. If you want to use VSTU for
  editing please use the special build linked at the bottom of this
  post.
• The compiler targets the C# 6 language.
• The compiler by default will still target the .Net 4.6 framework profile.
• Known issues
  
  
  • The Android/Mono build does not work properly with managed code stripping. Please disable managed code stripping for now.
  • For some projects, the Windows standalone player can crash on Windows 8.1. This is intermittent, so we would love to see any crash
    reports or data about this

Using .NET 4.5 code in Unity 5

Using a visual studio plugin: unmanaged exports, I have been able to export the C# .NET 4.5 to an unmanaged/native dll which I can use in Unity Engine.
This forces to call only simple functions, but with little work, it was possible for me to wrap the core of my engine.

Updating Unity Engine or not when working on a project?

The question is somewhat similar to the problem of source code conflicts:

i.e. should I follow CI best practices and update often or should I continue to code in my own little world only to perform a SVN merge with my peers' code 6 months down the track?

Sure the latter has less problems on a day-by-day basis but in the long run will most likely result in the code merge nightmare from hell.

In the case of Unity3D, if your plan is to make a commercial game, it may be wise to update Unity3D often as one would with source code. The reason being the longer you leave updating Unity (and associated 3rd party assets I might add) the higher the probability you will encounter conflicts or incompatibilities when you do decide to update (I speak from experience as I'm sure others will attest).

Additionally, Unity3D is continually being updated for the platforms you intend to target including bug fixes; performance enhancements or other additional features.

Decouple from Unity3D Using MVVM

The general consensus with game studios and Unity3D is to de-couple your actual processing logic from Unity3D entirely by using a bridging pattern and MVVM. This allows you to write in plain old Visual Studio where you can rapidly prototype and unit test following a MVVM pattern. Only the V is aware of Unity3D usually represented as a Unity3D behavior. Tell me more

The immediate benefit for you is that the majority of your code won't be affected by changes in Unity3D, if performed wisely.

Unity compile errors after upgrade

It sounds like you have an old version of package manager. Try to "Reset packages to default".

---

Related Topics