JetBrains/resharper-unity

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?

lingongames-mikael

@lingongames-mikael

It compiles in Unity and I can create builds. In Rider is listed as an error in solution.

Where communities thrive

People

Repo info

Activity