Base classes and interfaces transform into invalid import statements

[craigktreasure]

Using MTT 0.4.7.

Transforming a class that inherits from an interface:

public class UserProfileViewModel : IIndividual

Results in an interface like the following:

/* Auto Generated */

import { IIndividual } from ""

export interface UserProfileViewModel extends IIndividual {
...
}

It would be great if there were options to specify how to handle these. For instance, in the example I gave, I don't care to emit the interface in the TypeScript definition.

I haven't dug into the code you're using to load the C# yet, but if you're only loading the C# files in the WorkingDirectory, you may never encounter these objects anyways.

If you're open to it, I think reflection could be used on the output binary to find attributed models. Then, those attributes could be used to configure how the model is transformed. Project references would likely need to be resolved, but I think that could be retrieved from msbuild. What do you think?

P.S. I still think it's crazy that after all this time, you're the only one I've found who cares to support .NET Core\Standard in the build rather than through a VS Extension. Thanks for your hard work.

[CodySchrank]

You're correct, as long as your C# interface is not in the working directory then it would not be encountered. I very rarely use interfaces in my dto's so it's something I haven't really considered yet.

Honestly the code is quite simple and pretty much does a 1:1 translation, and it just keeps track of the necessary references for each file. I'm not sure what could be retrieved from msbuild regarding file references?

However I will look into handling c# interfaces to make sure that they are not included. You mentioned options, what options do you think would be necessary for this?

PS. Thanks! I also couldn't believe that something like this didn't exist.

[CodySchrank]

Good tip on the reflection. I didn't even know c# offered methods like this
https://msdn.microsoft.com/en-us/library/system.reflection.methodinfo(v=vs.110).aspx

MTT may be getting rebuilt...

[craigktreasure]

I stumbled into Dogma this morning. It does something similar to what I'm describing without the msbuild integration.

[CodySchrank]

@craigktreasure Hmm yea but I'm trying avoid using stuff like [ToTypeScript("my-module")] and [JsonProperty("hello")]. I want MTT to transform directly. Or do you mean the loading assembly part?

[craigktreasure]

If I understand you correctly, you want to transform directly from the C# source files. Is that right? That does keep you more lightweight I suppose. Do you mind me asking the reasons or requirements for doing so?

The attributes, like [ToTypeScript("my-module")] and [JsonProperty("hello")], would require you to be dependent upon the compiled assembly to perform reflection. If you are trying to avoid the dependency on the compiled assembly due to requirements or other reasons then that makes sense, but it is possible to schedule your build task after the build has completed.

[CodySchrank]

@craigktreasure As you can probably tell I'm pretty new to C# and .Net in general. Correct, the original intent was to keep the utility as lightweight as possible.

There aren't any restrictions to compiling to a binary per se, its just unnecessary for my use case. I built this for work and we have simple DTO's. There are also other utilities that do that same thing, that already offer data annotations and templates like you are suggesting (however they have other restrictions, mainly less portability).

I tried to implement a new system a couple days ago that compiled each file to use reflection but I was having trouble keeping track of the references. I just don't have the time to investigate this further right now! Maybe in the future.

But for now, MTT will not compile the files.

[craigktreasure]

Thanks for the response. I'll leave this open for you since it is a "bug," but feel free to close if you choose not to fix it.