Wrong define symbols in packages

[SugoiDev]

Rider will fail to see project defines when opening a cs file that is in a package.
Unity compiles packages in the same "context" as the normal assemblies. The define symbols are the same as those from the normal assemblies.

For example, opening PackageManagerWindow.cs from the Package Manager UI package shows this:

Notice how the #if UNITY_2018_1_OR_NEWER branch is disabled. But, it should not be, since the symbol UNITY_2018_1_OR_NEWER is defined.

---

This report applies to the latest nightly Rider with Unity 2018.2

[van800]

related to #629

[van800]

This files are Misc file, we shouldn't analyse them. @kashmervil Lets take a look?

[SugoiDev]

I usually create separated DotSettings files to exclude each group of third party assets from analysis easily. When I need to read the code or fix something, I disable the respective DotSettings layer to have full analysis on the group.

This has been very useful for me when dealing with external code. With Unity packages, we usually[1] won't edit them, as they are meant to be read-only. But, having the possibility to enable analysis on them is still very useful when reading/navigating the code.

[1] I do edit some on occasion. Usually to workaround a bug that is yet to be fixed upstream.

[tbg10101]

Actually, I think this happens for any code that is under an assembly definition file (.asmdef), not just for external code.

If I use #if UNITY_EDITOR in an assembly then the content always grayed-out, even though UNITY_EDITOR is defined in the .csproj file which was generated by Unity.

[van800]

@tbg10101 This doesn't reproduce for me. Can I take a look at csproj and asmdef?

[tbg10101]

Apologies, it looks like this was just because the project was not using the correct profile.

[sini-codes]

Good day! Are there any known workarounds to this issue?

[marwie]

Hello, everyone. Any news on this?

Im having this issue right now in AR Foundation samples using Unity 2019.3.15f1 when looking at the XR Interaction toolkit package
In case you need another example :)

Rider is 2020.2 EAP 3

[Bastienre4]

I also encounter this issue.

The correct code compile but it's grayed in the Rider IDE.
I guess the repro is write the #ifs firsts (also make sure the script is in a separate asmdf) and then add the scripting symbol in Unity's project settings,

[citizenmatt]

The problem here is that these files are not part of a project, so there is no project context for Rider to work with. It knows some things - e.g. it gets navigation information from PDBs and so on. But when parsing and highlighting, without a project context, it sits in what we call the "Misc Files" project, in which there are no define symbols set. And that means something like #if AR_FOUNDATION_PRESENT will always evaluate to false.

However, this is mainly a presentation issue. Since these files aren't part of a project, Rider isn't actually analysing them, it's just showing them, and trying its best to highlight. There's not a huge amount we can do about this, but it's something we can look at in a future version. One workaround is to use the checkboxes on Unity's External Tools settings page to generate projects for different package kinds. This isn't encouraged, however, as this causes Rider to treat your packages as user code, and they're not. The code lives in Library/PackageCache and any changes can and will be overwritten by Unity at more or less any time. It also increases the size of your solution, and makes Rider do more work analysing files that won't be changed.

[tbg10101]

I've begun to run into that "no analysis" issue while working on Unity packages.

For example: https://github.com/tbg10101/DOTS-Hybrid-Simulation-Worlds

I can check that repo out and open the example project with Unity. Then, when I open the solution in Rider, only the package scripts are analyzed but none of the scripts from the example project are.

This seems bizarre and the opposite of what @citizenmatt described but has the same effect.

[citizenmatt]

This is a bit of a special case due to the layout of that project. The sample project is in a folder called Examples~. That ~ means that Unity will ignore the folder and not try to import it into the asset database. Unfortunately, Rider (or more specifically the IntelliJ Platform that Rider is built on) includes *~ as a mask of files/folders to completely ignore, because it's a common pattern for older text editors (think Vim) to create backup files, and we don't want to accidentally check that into source control.

So Rider (mostly) ignores the files under the Examples~ folder. This explains why the files in the Unity project are not processed, because the whole project is under this folder. But the main package is referenced with file:../../.. which means it lives outside of the Examples~ folder, so Rider does not ignore it, and you get analysis. That explains the behaviour you're seeing, and you can fix/work around it by removing the *~ from the "Ignore Files and Folders" setting in Preferences | Editor | File Types. We can't do this automatically, because a) it's a valid pattern and b) there's no API in the platform to do so.

But things are complicated further by the fact that while the IntelliJ Platform side of things ignores this file, the underlying ReSharper engine (that's doing the C# analysis) doesn't follow the same rule. So we've got the analysis actually happening, just not being shown in the UI. We should be handling this a bit more coherently. I've raised an issue for this: RIDER-48339. And since this is a fairly common Unity pattern, it would probably be a good idea if we notify the user when we get into this scenario: #1784

The issue of non-project/read-only packages not using the correct defined symbols is a separate issue, and there is actually stuff we can do here. I'm planning on getting it working for Rider 2020.3

[pshtif]

Hi any info on this? The explanation of packages being read only so it doesn't matter that much is not actually true. You can embed packages which we do, to edit them and they still reside outside of the project folder so the mentioned issue is there.

The ability to embed packages for editing is used heavily in our pipeline to update custom packages and then publish them to repository. Instead of having separate project with packages folder directly inside it. As packages behave differently so developing pacakges and their testing and workflow is way better with embedded packages use.

[citizenmatt]

Can you explain how you're embedding your packages, please? If you make them part of your project (e.g. copied into Packages, or referenced with file:), they should have a .csproj generated for them, in which case they become user files and part of the solution and #if highlighting works as expected.