Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Base classes and interfaces transform into invalid import statements #10

Open
craigktreasure opened this issue Aug 9, 2018 · 7 comments
Assignees
Labels
bug Something isn't working reflection Only possible with reflection

Comments

@craigktreasure
Copy link

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
Copy link
Owner

CodySchrank commented Aug 9, 2018

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 CodySchrank self-assigned this Aug 9, 2018
@CodySchrank CodySchrank added the bug Something isn't working label Aug 9, 2018
@CodySchrank
Copy link
Owner

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
Copy link
Author

craigktreasure commented Aug 9, 2018

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

@CodySchrank
Copy link
Owner

CodySchrank commented Aug 9, 2018

@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
Copy link
Author

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
Copy link
Owner

@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
Copy link
Author

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.

@CodySchrank CodySchrank added the reflection Only possible with reflection label Sep 24, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working reflection Only possible with reflection
Projects
None yet
Development

No branches or pull requests

2 participants