How to conditionally compile `InternalsVisibleTo(…)` assembly info?
Multi tool use
How to conditionally compile `InternalsVisibleTo(…)` assembly info?
Using .Net Core 2.1, my AssemblyInfo.cs looks like this:
using System.Runtime.CompilerServices;
[assembly: InternalsVisibleTo("RazorWare.Core.Media")]
[assembly: InternalsVisibleTo("RazorWare.Core.Business")]
#if DEBUG
[assembly: InternalsVisibleTo("RazorWare.CoreDL.Testing")]
[assembly: InternalsVisibleTo("RazorWare.CoreDL.Testing.CreateNativeWindow")]
[assembly: InternalsVisibleTo("RazorWare.CoreDL.Testing.CreateEventPump")]
#endif
...and a screenshot of relevant project properties:
The assembly attributes surrounded by #if-#endif are not grayed out when the project is set to Release. How can I coerce the compiler (VS???) to recognize the #if-#endif directive?
#if-#endif
Release
#if-#endif
Actually just found a question that suggests unchecking "Define DEBUG constant". However, the properties page will not let me uncheck.
– IAbstract
Jul 1 at 5:44
Well that Tick is the problem, since it is defining the thing the
#if is checking for. Hmmm.... Does your project file import from any of your own '.targets' files?– Richardissimo
Jul 1 at 6:26
#if
Do you use ReSharper? If so, it's a bug in the ReSharper engine which I've experienced with projects using the new project format. The conditional symbols work, , ReSharper just has issues displaying it properly. Notice also your conditional symbols seem to repeat each other. That is a bug with visual studio. I had to fix that by manually editing the project file and then never using the property screens to edit those values. It seems to only be an issue (in both cases) when the project is mulitargeted.
– pinkfloydx33
Jul 1 at 9:02
As it turns out there is a bug in VS. If I unload and reload the project, the IDE shades out the code and the compiler obeys the directive. github.com/dotnet/project-system/issues/2733 The link also describes the bug @pinkfloydx33 raises.
– IAbstract
Jul 1 at 11:01
1 Answer
1
If you can't untick DEBUG, then use your own symbol, e.g. INTERNALS_VISIBLE_TO_TESTING. Define that in just the RELEASE configuration.
INTERNALS_VISIBLE_TO_TESTING
However, I personally wouldn't bother with any of this: I'd include the InternalsVisibleTo attribute in both configurations. It does no harm to have it in the release configuration, and it has a distinct benefit: it means you can test the actual binary that you're going to release.
InternalsVisibleTo
Valid point on testing the release binary.
– IAbstract
Jul 1 at 11:02
One reason against exposing internals in a Release build with an unsigned assembly is that it means a third party can write code to access your internals simply by naming their assembly using a name from one of these attributes, which can be seen by reflecting the assembly. This isn't an issue for signed assemblies.
– Richardissimo
Jul 1 at 21:03
@Richardissimo: As opposed to disassembling to IL, adding the attribute themselves and reassembling? If someone wants to do it, they can do so pretty easily either way. (Or just use reflection...)
– Daisy Shipton
Jul 2 at 5:24
By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.
"Define DEBUG constant" (eg. DEBUG conditional symbol) is shown checked - is that.. desired?
– user2864740
Jul 1 at 5:39