.NET-Obfuscator VS dotnet-script

I've tested a few from this list: https://github.com/NotPrab/.NET-Obfuscator

Have a look here, https://github.com/NotPrab/.NET-Obfuscator . We use Pre-emptive Dotfuscator, they have a community edition which is really good. I honestly don't understand the reason for most of the answers to your question. If you feel obfuscation will add value to your project for you, then use whatever you want. Not every project sits behind a web server.

Beyond that, there are also obfuscation utilities that can obfuscate your published code. (The public API surface remains intact to maintain compatibility, but everything under that becomes obfuscated.) There are many options to help protect your code: https://github.com/NotPrab/.NET-Obfuscator Dive in and see if any floats your boat.

The term you're looking for is obfuscation. This seems like a good roundup: https://github.com/NotPrab/.NET-Obfuscator

Adding packages is `dotnet add {PackageName}`. That's it.

Worrying about version compatibility for new projects has stopped being an issue long time ago. The package either targets NS2.0 or whatever latest LTS currently is, in which case you just add its reference, or it doesn't in which case you use something else.

If it does, in 98% situations it just works. In the last 2% it has native dependencies which means either a) the package ships with binaries build for all popular platforms, b) the package adds a platform-specific dependent package automatically, or manually and mentions that in README, or c) the package comes with windows only native dll, which is happens with ancient poorly maintained packages, it's a rare case nowadays but it does happen.

As someone whose primary PL is C#, I found https://github.com/waf/CSharpRepl and https://github.com/dotnet-script/dotnet-script far more accessible and useful. Compilation caching for the latter works relatively well to make startup latency tolerable.

Or I just do `dotnet new console -o MyScriptName --aot`, echo code into Program.cs and `dotnet publish -o .` it. Some do that with Rust as well. Especially useful if you need your script to go through a lot of data quickly and parallelize that well too.

Especially because these languages are only one package/install away and not two. I don‘t really get for which audience is targeted here. Usage in JS projects maybe, but then why not write it as npm tasks. ..

I‘m playing around with dotnet-scripts [1] at the moment (C# shop mainly) and this has the same issue imho. The reason why I looked into it was because we have developers not accustomed to bash etc. I still find it silly and would rather use ruby so…

[1] https://github.com/dotnet-script/dotnet-script

>making powershell actually enjoyable to use

My solution was to stop using it and instead use dotnet-script

https://github.com/dotnet-script/dotnet-script

Scripting with the full power of modern C# has been a huge win for me. And same/similar scripts will work on Windows/Linux/Mac. As my work language is C#, I don't have to context switch to another language for scripting.

I usually create a container that has all database migrations and tool to execute those migrations. I name migrations as [yyyyMMdd-HHmm-migration-name.sql] but please feel free to use any naming scheme, keep in mind how the tool would order multiple files to run those migrations. I have also added a wait-for-db.csx file that I would use as the entry point for database migrations container. This is a dotnet-script file and would be run using dotnet-script. I have pinned the versions that are compatible with .net sdk 3.1 as this the version roundhouse is build against at the time of writing.

thanks, this is very good idea too, and with dotnet-script we can publish executable out of the script!

It sounds like this is feedback for the author of the dotnet script tool: https://github.com/dotnet-script/dotnet-script

Yes, you can have single-file scripts too. There might be more options to achieve this, but the one that I use is running *.csx files via the dotnet-script (https://github.com/dotnet-script/dotnet-script).

I do agree.

I think .Net has got it right. And dotnet-script [https://github.com/dotnet-script/dotnet-script] has been a game-changer for me with a REPL-like experience for unit testing and writing command-line utilities.