Not sure that this one is for me. I always try to maximize obvious-ness in my code so that the next programmer (or the future me) will have an easy time understanding it. Launching a block of code through an environment variable value is very cool, but way too magical for what I value which is obvious-ness. Comments could help, but I've met many junior programmers who are too proud or lazy to read the comments. I will however start logging the value of that environment variable in my startup code, just in case some other member on my team doesn't share my aversion to magic. Thanks for another great video!
It’s so cool to see stuff like this! I remember many moons ago I created a way of loading other assemblies with WebForms into my main WebForms project. We had some huge forms with many files that all had same structure so I created a project template for it and the main project would load it dynamically using virtual routes. It was kind of a reflection hell and I don’t remember how I even did it, but it felt so good when it worked!
This feature while cool, it seems to me like a malware paradise. A malware can use it to hide itself from Task Manager, operating from inside random non-malware processes. Also it can read everything including passwords and encryption keys from within the process.
So I've always poked around dotnet (around version 3) and really loved the syntax and especially love powershell. But since I discovered your channel, I've moved from casual programmer, to whatever the next level is. Coinciding with my new obsession with microcontrollers, you've really just made what would have been an insane amount of hours of staring at code a much smoother process. Like, you make advanced stuff digestable. Thank you!!
i've done this before, you can also use c# compiler to generate assembly directly to memory and execute it from there, therefore you could run c# code (not dll) directly from your application
I'm happy to know how hooks works. And also hapy that probably I'll never use it. The fact that you can't use nuget packages installed dirctly into the hook library is a serious disadvantage. For me hooks are relatated to the platform infrastucture. And from architectural point of view if I'm not required to use it I'll just not use it or at least not with hooks.
.net framework was comparatively safe when it comes to vulnerabilities and RCE. This one feature will turn that around for sure. its only time before this feature becomes the Achilles heel for dotnet core.
Hi, i love your videos. I have two questions: - If i want to prevent code injection by this way, can i clean environment variable at Program? - What's happen if hook throw a exception? The entire application will shutdown? Thank you!
Great content, as usual! And regarding the workshops, I am very happy to see you're coming to Iași, a beautiful city in Romania. Actually it is the former capital of Romania and the 2nd largest in the country, with a big community in IT industry. This is why I believe it deserves to be mentioned in your announcements, next to "dotnetdays", the same as all the other more known cities.
Great content, as always! Could you do a video about plug-ins? I am interested if it's possible to deploy custom logic to client apps as optional libraries.
Very cool, this will definitily come in handy. I knew about the assembly resolver, but not so much about the hooking. Also i didn´t knew that you could redirect the console logging like that - i like that. Thanks for sharing.
So it's a sort of plugin architecture that has only one hook but it's available in any .NET application. Would be cool to see this generalised to simplify adding plugins !
I love how this is available, and it seems mature enough for most scenarios that involve basic application intermediation like status and health logging. Most other purposes would be better to directly include in the source project that is being hooked. That being said I wonder, is that functionality abstracted anywhere? I believe that there's a lot of boilerplate just to get some key parts of the hook running like the assembly context loader
You can take this one step further and inject services at application startup. Dotnet uses this in their SpaProxy nuget package. You can see it in action by creating a new React web app template.
It’s only a "risk" if you can’t trust where you run your app. If your app runs on something you don’t trust, anyone can do anything with your app beyond just injecting code
As far I I could see this is only running something on the side, it's not directly integrating with the running app but intercepts things that are already somehow interceptable.. @Nick correct me If I am wrong but the DLL can't directly interact with the code in the running app.
Hey Nick, this is great, I will be using this, so thanks so much for the introduction to this approach, I think it is very cool, however.... Hot Reload? Is this one of the limitations that you mentioned/hinted towards the end of the video? Slightly off topic,but also related: I have a Blazor WASM project that I've been working on that uses 'AdditionalAssemblies' and hot reload has never worked for me, so I'm curious that if you have figured out or know that this works with Hot Reload, that perhaps I'll be able to figure out a way to get my Blazor app to work with hot reload too. p.s. I have been asking for help on Microsoft forums/posts/github but nothing helpful as of yet...
I see one use-case: in CI pipeline run all the tests with different cultures (set it in the hook from an environment variable) [side note: you can do this in .NET Framework as well by using IL weaving tools out there]. IMO there is very little reason to use this technique for code you control.
Yep, that is an interesting use case. However, I prefer to use parametrized tests and only those depending on culture will receive that culture as a parameter. This is more efficient, since you run the test suite once, and use the test framework's (NUnit in my case) test parametrization features. A better use-case for tests IMO is to perform test report aggregation -- if your tests output generic data that needs to be reported, the hook can transform that data into whatever your test reporting tools (eg. Allure) would prefer. This may help you swtich test report providers without rewriting all your tests, just use separate hooks
Useful hook. I would use it! Only problem is the magic.. but for debug stuff it's worth it. A little limited in the classical ms way, but still cool. I have made a similar thing with events, where I would have static events, construct a class in the program level, which would bind its member methods to the events. When ever any part of the app needed to use it they would just invoke it. I didn't need to keep it as a member any where, in fact I discarded it when new-ing. But this hook is probably better, since app code didn't have to explicitly call it from what I gathered?
I have been writing dotnet code for a really really long time and had no idea about this. This is pretty awesome!! Is there any official dotnet docs on this feature?
So some infrastructure type of developer can significantly change running systems simply by deploying a new DLL. If it breaks everything is broken? If it performs badly we slowed the whole company down? Interesting but very dangerous. There's no contract with the developer to upgrade based on semantic version as with packages. I see huge nightmares ahead.
This does not seem to work for a WinUI 3 desktop app packaged with Msix - the environment variable is null... any thoughts, anyone? (Works if commandName is set to Project in the launchSettings.json file)
Hi Nick thanks for this great video. A question: is the text writer example at the end thread safe? I see that text writer has a wrapper called Synchronized that is thread safe. And not sure of the performance. thanks.
Hello Nick, I got a question! Now I'm calling an api using IHttpClientFactory and the api returned for me 15Million record then I have to save them to the db. The problem is the whole process takes a lot of time! like 10Mins or so! I tried BulkInsert and BulkSaveChangesAsync and all other solutions that are available there! even I used Batching! I want this whole operation takes only 1S or so! Can you help in this or suggest someting? btw I'm using EF Core.
Stop using EF Core brand explore options to bulk load data direct to SQL. Mysql has the ability to bulk load a CSV file which is many times faster than using INSERT. Other dbs do too.
Not gonna happen, it would take longer than 1s just to download the data to a file, add deserialization and database and this should take at least 10s of seconds. I would do raw bulk insert from a DataTable without EF, intelligently split the incoming data into fragments by crawling over the incoming stream and deserialize one by one as needed to save memory. If the records are big it might be faster to do 2 rotating DataTables for the bulk insert in parallel, write one to DB while other is deserializing and preparing next batch. It sounds like you are using a massive amount of memory to deserialize all the records, only then start writing to DB, that would be much slower.
@@the-niker The only way you're going to get down to the time you want is to remove all the extraneous handshaking and back and forth. That means bypassing the API and getting the raw data as a CSV, and then importing it using direct LOAD INFILE or whatever your equivalent is. If A wants to talk to B the quickest way is direct. No matter what tricks you use, going A to B via X Y and Z will never be as quick. Good luck.
@@richardclarke376 Yes, ideally you are right, but I am assuming a JSON/XML REST API and not CSV on the API side. If you can get your hand on something native to the database like a CSV, that would be much faster.
For those doing this with Visual Studio; is there any way to stop VS from publishing to Nuget Package? In .NET Framework, it used to just dump the deployed output to the publish folder, but now it wraps it all as a Nuget Pacakge automatically. I can't find any way to make it stop. I don't want a Nuget Package; I just want a DLL file.
Nick, Happy New Year! Thank you for great explanation as always. I want to ask, If I could use IApplicationLifetime service instead of this approach, subscribing to it events ApplicationStart, ApplicationEnd? And what is the difference?
This feature is very interesting!!! But may it could be a vulnerability? If I understood, this allow us to inject any dotnet DLL justing using a enviroment variable, incliding a DLL capable to access the restrict application data, am i right?
How could it be a vulnability? It requires the environment you are running on to be compromised. If your runtime environment is unsecure, anyone can inject anything no matter what
As a developer that got the assignment of making sure our codebase have logging this could come in handy. However I just might use it to spam the Primary dev of a solution to get his/her act together and implement logging. Since I've almost done using Roslyn analyzers to go through the codebase and detect this it's not hard to go one step further and creating DevOps tasks for this as pr project and pr Primary/secondary developer.
Do you know if setting the ProcessExit event handler in the startup hook will overwrite a potential ProcessExit event handler that would have been set in the application? Or will both event handlers run?
This workaround can be applied directly to the nuget package without a need to create a bridge. This is better in my opinion if you don’t have many packages.
Thanks for quality contents Nick. I have a completely unrelated query. As I see your terminal screen gives information about current branch name ...etc. I wonder how can I get same functionality ? ( OS : windows ) Thanks
@@nickchapsas Help me understand this logic? The same was probably said about Active X in the browser, but we all know how that ended. As a developer, this ability to "hook" my (malicious) application into anything that runs within the dotnet framework seems ripe for exploitation since it's such a benign vector that almost nobody would ever think to check. If I were to make a recommendation to the dotnet team it would be to only allow for explicit references to hooks by way of some easily editable configuration file. This would at least prevent global execution from occurring.
@@qtxsystems You can "hook" code into any application if you control the medium it runs on. It doesn't matter if it's C#, C++ or Go. The moment you control the runtime environment you control everything.
