Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Matt Ellis
    @citizenmatt
    And then in the Extension Manager settings add a new feed and point it at the local directory that you downloaded it to e.g. “local”: c:\temp or wherever, then it will appear in the extension manager
    RamsayGit
    @RamsayGit
    @citizenmatt Thank you for your support, local installation worked nicely.
    Matt Ellis
    @citizenmatt
    :thumbsup:
    Ethan Chan
    @metakirby5
    hi all - i was wondering, is there a way to specify methods as expensive (like with a custom attribute)? it's kind of the inverse of what "performance critical context" does - it should add an indicator to the lines where that method is called, as well as the lines where methods which eventually call the expensive method are called.
    Matt Ellis
    @citizenmatt
    Right now, no, although that’s a nice idea. Right now, we recognise a number of Unity APIs as being expensive, and this propagates within a single file. So any called methods are marked as a performance critical context, and any expensive method inside this context is highlighted, no matter which method it’s in. And that propagates back to the original method. So if Update calls InnocentLookingMethod which calls BusyMethod which calls GetComponent, then InnocentLookingMethod will be marked as an expensive method.
    This all works within a single file, we’re investigating expanding that cross file with 19.1
    What methods would you expect to mark as expensive?
    Ivan Pashchenko
    @IvanPashchenko
    @citizenmatt we can provide an Attribute as a part of EditorPlugin if we're talking about user code :)
    Matt Ellis
    @citizenmatt
    That’s actually not a bad idea. Or provide context actions to create an internal class directly inside a project, which would work with 3rd party assemblies/packages.
    I’ve written it up as an issue: JetBrains/resharper-unity#1030
    Matt Ellis
    @citizenmatt
    I think this is a really nice idea, with a good overlap with external annotations for third party assemblies
    Ethan Chan
    @metakirby5
    thanks! i was indeed talking about user code.
    in addition to the existing feature @citizenmatt mentioned, i also was interested in the inverse - where any function that uses an expensive function is marked as an expensive context recursively, rather than any function used by an expensive function (which is the current functionality).
    Matt Ellis
    @citizenmatt
    There are currently no plans for that kind of feature, and for the same reason that they’re “performance indicators” rather than traditional warnings. Basically, they’re all valid API calls, and don’t cause performance problems by themselves, but when used e.g. every frame. For example, one of the “fixes” to calling GetComponent in Update is to do it in Start and cache the result. But we wouldn’t want to mark Start as performance critical.
    Really, this is advice to indicate that you’re potentially doing something expensive when you should be as lightweight as possible, but it’s not a substitute for profiling.
    Jurjen Biewenga
    @JurjenBiewenga
    Did anyone get the chance to look at JetBrains/resharper-unity#1167 ?
    Matt Ellis
    @citizenmatt
    Hey. Yes. I need to add feedback, sorry haven’t had much chance lately (I’m in the Unite keynote in Shanghai right now 😄). Sadly, it’s not the right approach. The api.xml file is intended for event functions, rather than marking arbitrary APIs as used.
    I suspect you’d get an interesting side effect of being able to define a class that implements IPreprocessBuild and then use the Generate Code -> Unity Event Functions dialog to add the missing methods
    The preferred way to implement this would be to actually add it directly into UsageInspectionSuppressor. Essentially, if method is IPreprocessBuild.OnPostprocessBuild or property is IOrderedCallback.callbackOrder, then mark as in use
    Matt Ellis
    @citizenmatt
    I’ll add more to the issue
    Jurjen Biewenga
    @JurjenBiewenga
    Alright, thanks!
    Jurjen Biewenga
    @JurjenBiewenga
    Hey! Just popping in to see whether someone has had time to check out my update to #1167
    Adavidoaiei Dumitru-Cornel
    @adavidoaiei
    Hello, for ide rider is it a channel?
    Matt Ellis
    @citizenmatt
    Hey. Sure, the Unity support in this repo is for both Rider and ReSharper.
    Adavidoaiei Dumitru-Cornel
    @adavidoaiei
    OK, thanks, I will keep looking on your channel
    Jurjen Biewenga
    @JurjenBiewenga
    Hey, I got a new laptop and installed Rider again and tried opening the Resharper-Unity project and I'm getting a whole bunch of Microsoft.DOT.netSDK missing errors. How can I fix this?
    Matt Ellis
    @citizenmatt
    Have you installed .net core?
    Jurjen Biewenga
    @JurjenBiewenga
    Yeah
    Matt Ellis
    @citizenmatt
    What msbuild do you have selected in Toolsets and Build?
    Also, run ./build.ps1/.sh first
    Jurjen Biewenga
    @JurjenBiewenga
    I've ran build.ps1
    And I've tried every msbuild in toolsets and build
    I also downlaoded the jetbrains fork of msbuild
    And that kind of worked except for the gradle launcher
    Matt Ellis
    @citizenmatt
    And it all builds ok from the shell scripts? That does suggest that Rider isn’t using the same msbuild as the scripts. Are you are Windows or Mac?
    Jurjen Biewenga
    @JurjenBiewenga
    Yeah I think it runs from fine from the shell scripts, I'd double check but I'm at work
    I'm on windows
    Jurjen Biewenga
    @JurjenBiewenga
    The shell scripts do work
    Matt Ellis
    @citizenmatt
    Did you get things working? (Been on vacation)
    Jurjen Biewenga
    @JurjenBiewenga
    Nope
    Been on vacation as well :P
    Matt Ellis
    @citizenmatt
    Make sure you’ve installed the .net core SDK, not just the runtime
    Jurjen Biewenga
    @JurjenBiewenga
    Oh yeah I have, I forgot about this
    Matt Ellis
    @citizenmatt
    Heh. Is this still a thing? Shall we just leave it until next week when we’re both in Copenhagen? :)
    Jurjen Biewenga
    @JurjenBiewenga
    Haha sure
    I haven't actually tried again
    Matt Ellis
    @citizenmatt
    Bring your laptop, we’ll get it working :)
    Jurjen Biewenga
    @JurjenBiewenga
    Sure thing
    I'd probably just have to install VS
    lingongames-mikael
    @lingongames-mikael

    Hey! I've got a bit of a weird issue and I'm stumped as to how to fix it:

    I'm using Unity 2018.4.3 and Rider 2019.1.3. In my project, I have Firebase integrated. Firebase uses https://github.com/parse-community/Parse-SDK-dotNET to add newer .NET functionality (like Tasks) to older .NET standards. Somehow, Firebase's SDK takes care of the naming clashes when using the .NET 4.x scripting runtime, as I am in Unity 2018.4.3.

    In Unity the project compiles nicely, but in Rider I get an error when awaiting FirebaseApp.CheckAndFixDependenciesAsync (a method returning Task<Firebase.DependencyStatus> (extra sidenote: the Task class returned is from within Parse-SDK-dotNET, not the standard .NET runtime)):
    'Type 'System.Threading.Tasks.Task<Firebase.DependencyStatus>' is not awaitable.'

    The code functions as it's supposed to, so it seems like Rider doesn't understand what's going on between the different assemblies. If I try the stripped down code:

    public Task<DependencyStatus> InitFirebaseAsync()
    {
        return FirebaseApp.CheckAndFixDependenciesAsync();
    }

    I get the error:
    Cannot convert expression type 'System.Threading.Tasks.Task<Firebase.DependencyStatus> [Firebase.App, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]' to return type 'System.Threading.Tasks.Task<Firebase.DependencyStatus> [netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51]'

    Which points to a clash between the two assemblies. How can I get Rider to figure out the difference?

    Thanks in advance!

    Ivan Shakhov
    @van800
    Does it compile in Unity? Does it compile in Rider?