why Light Inject's source code all in one .cs file [closed]

Question

like this https://github.com/seesharper/LightInject/blob/master/LightInject/LightInject.cs

It's hard to reading, is there any deep meaning?

Gawky

It's completely up to the author. Though it is worth wondering why he has 5k lines of codes in one file – Fanaticism

Hey guys, why closed? did you see the author's answer? it's a meaningful question! – Gawky

@Gawky unfortunately this is how many Stackoverflow members treat users, especially new users. I always do my best to get questions reopened because they have value. – Chiaki

Answer 1

Being the author of LightInject, I feel I should comment on this :)

Say that you are a library developer and want to be able to utilize an IoC framework internally without taking a dependency on a third party assembly. By using the source version of LightInject, this can be done quite easily and you can still ship your library as a single assembly.

Many framework developers choose not to use an IoC framework just because they don't want that extra dependency.

The alternative to this would be to use tools like ILMerge that is capable of merging two or more assemblies into a single assembly.

This is a far more advanced option and would also require an extra build step that performs the merging.

Note that LightInject comes in two flavors, the source version where all the types are internal and the binary version that acts just like any other third party dependency.

Taking on a dependency might not seem so bad at first, but if you are a framework developer, you could easily run into issues if the consumer of your framework uses another version of the same dependency

Best regards

Bernhard Richter

Vesicle

Thank you for the clarification and to the OP for being brave enough to post an odd but reasonable question. I have to admit when I first cruised through the LightInject docs I bumped into the explanation for internal scope only source code usage and thought "why no conventional DLL with a public api?". This reply helps clarify the dual mode usage/deployment scenario. Makes perfect sense now, I will be using the LightInject library packaged as a standard DLL. – Gratify

I want to use LightInject because it's the fastest. Why doesn't LightInject support xml configuration? Seems like specifying the maps in code defeats the purpose of DI? (DI newbie here). Thanks. – Blackout

@Blackout you never need container services registration via XML. I would also go as far as to say it is literally an antipattern. If you seriously need that level of variance MEF's component architecture that can support addins during runtime is a much better starting point. – Chiaki

@ChrisMarisic, I'm not arguing, I just don't know. So add-ins would be configured in the xml? – Blackout

@Blackout I would never use config files by choice for any reason other than appsettings/connectionstrings. Outside of that there's alot of forced usage of config files by .NET sadly. – Chiaki

Answer 2

It makes integration as source in another project easier: simply add one file to your project and forget about it. This is a supported installation scenario according to the official website of LightInject, there's even a NuGet package for it.

If you want to read it, I'd strongly suggest opening it in Visual Studio and using the code navigation features to find what you want, e.g. VS 2013's Solution Explorer can display the classes inside of a file as children of that file.

Heterothallic

you're right, thanks. why do you know this thing? maybe you are the author.... just a joke :) – Gawky

It's just an educated guess. Maybe the real reason is something else I haven't thought of. – Heterothallic