search

stakx / TypeNameFormatter

A small .NET library for formatting type names à la C#.
MIT License
33 stars 4 forks source link

Can't use the formatter inside razor templates #30

Closed bugproof closed 6 years ago

bugproof commented 6 years ago

I'm using razor templating engine to generate source code. I found your library which seems to solve one issue I have. The problem is I can't use GetFormattedName extension inside razor templates (*.cshtml). I get:

error CS0122: 'TypeName.GetFormattedName(Type, TypeNameFormatOptions)' is inaccessible due to its protection level

This needs some investigation why it doesn't work.

https://github.com/stakx/TypeNameFormatter/blob/40e05e8cac223af8f0c5add69ce0ca20e5a088f6/src/TypeNameFormatter/TypeNameFormatter.cs#L20-L27

Is TYPENAMEFORMATTER_INTERNAL really necessary? Why can't the class be just public all the time? It seems like it was defined during compilation and the class is internal.

Also see this issue for reference: https://stackoverflow.com/questions/42264992/using-internal-properties-in-razorengine

stakx commented 6 years ago

@lecoque - If you put the following in your .csproj, then the TYPENAMEFORMATTER_INTERNAL conditional compilation symbol will not be defined, resulting in TypeName being declared public:

<PropertyGroup>
  <TypeNameFormatterInternal>False</TypeNameFormatterInternal>
</PropertyGroup>

(This is an "official" build flag planned for just that purpose, btw. I just haven't documented it because I figured that almost noone would need it.)

Please let me know if that works for you.

stakx commented 6 years ago

Is TYPENAMEFORMATTER_INTERNAL really necessary? Why can't the class be just public all the time?

To answer that other question: Yes, for source code packages, this is necessary.

Let's say you have a solution with two projects A and B, where A is referenced by B. Now you add a package X to A. Normally, you would expect that the functionality in X will become available only to A. If you want to use X in B, you'd normally let B explicitly reference X as well. (This is how assembly references have always been working.)

To get the same effect / meet this common expectation, source code packages need to declare everything internal such that they won't "spill over" into referencing projects.

bugproof commented 6 years ago

Thanks! Adding <TypeNameFormatterInternal>False</TypeNameFormatterInternal> did the trick!

Also thanks for the explanation why internal is needed :) I didn't know that.