I just tried the quick start of .NET Core on Windows, following the sample, I created a desktop application. What seems a bit weird is the "main" program is compiled into a "dll" and no longer an "exe" like previous C# code.
Does it mean, from now on, .NET Core compiles everything into an "dll", like java compiles everything into a "class", and no longer need the "exe" because .NET Core VM is the sandbox for all .NET Core apps, like JVM?
Yes, exactly. With dotnet core, Microsoft went a step towards Java/Node/etc style of workflow where you can do most things through a command line tool (dotnet.exe).
I think this makes sense because .NET Core dependencies are app-local, so the runtime isn't scattered everywhere arround the file system as with .NET Framework.
You can create exe also by publishing the project for Windows OS.
For example (.Net Core 2.0):
dotnet publish -c release -r win7-x64
You need to specify win7-x64 in RuntimeIdentifiers also in the .csproj file
Related
We developed our application and tested over DotNet core 3.1.101 and it was working fine but what happened is Microsoft updated dotnet core to 3.1.111 and it breaks our application and we are asking customer to downgrade the core version manually that doesn't seem to be good idea.
Can somebody Wixsharp/.Net expert suggest, how can we avoid this problem? Can we have side by side installation of dotnet core and use the desired on with our application? If yes, How can we do it?
If you are really dependent of the specific net core version, the best solution to you will be to use self-containing publishing (https://learn.microsoft.com/en-us/dotnet/core/deploying/#publish-self-contained). This will create the solid bundle from your code and the your current net core version. On the client machine your app will use the net core, which is bundled with app. User may have other versions of net framework/net core installed, but these versions will not affect your app in any way.
For example, the following will create 64-bit executable for Windows
dotnet publish -r win-x64.
After you got your bundle from publish command, you need just pack the whole bundle with wix as usual. Not need to perform additional steps to install net core.
Is there an obfuscation tool that can work well on the exe and pdb files that result from a dotnet core single file publish?
I am using dotnet core single file publish with the command: dotnet publish -r win-x64 -c Release /p:PublishSingleFile=true. This works great in giving me just two neat files an exe and a pdb file, which I am able to give to a client to run my application.
However, I am still concerned about its ability to be decompiled.
I tried using ILSpy and JustCompile on both the files and they luckily could not be decompiled with these tools. Is it then that my files are safe, or it is that the tools have not yet caught up?
If the latter, what obfuscation tool can I use to protect these files? I attempted to use Obfuscar which did not work specifically on the single file publish outputs, the exe and pdb.
Any suggestions on the obfuscation tools to use for this?
Disclosure: I work for the Dotfuscator team at PreEmptive.
We have tested and verified that Dotfuscator Professional handles this scenario on both .NET Core 3 and .NET 5.
Specifically, you must use Dotfuscator Professional's MSBuild integration, which is now our recommended method of using Dotfuscator Professional for new projects. However, Dotfuscator will not update .pdb files on .NET Core or .NET 5, so you will not be able to debug builds which use Dotfuscator (e.g., Release builds). You should not ship .pdb files to untrusted users.
You can decompile .NET Core self-contained executables if you manually unpack them:
Can .Net Core 3 self-contained single executable be decompiled?
You would have to run the obfuscator as part of the build process, before the individual assemblies are compressed into the single file. That's probably possible if you add a custom MSBuild target that executes the obfuscator, and use the BeforeTargets attribute to integrate it at the correct point in the build process. But I haven't looked at the .NET core build system in detail.
You can use Obfuscar.
Use it in obj directory after target Compile and then copy obfuscated files to directory.(replace with original files)
I have noticed that both dll and exe files with the name of the project are created on Windows when compiling a .NET Core console application. Why is that? In full .Net framework only the exe file would be created.
Prior to .Net Core 3.0, only the dll was created (although you could still do a single file build that was platform-dependent). In these cases you had to use the command dotnet MyProject.dll to start your program.
With .Net Core 3.0, they added the exe, which is still really just a wrapper around the command above. On other operating systems it also creates an executable file, it just names it MyProject instead of MyProject.exe
If people have old scripts that still make the dotnet command, this setup doesn't break them, but if you want to just use an exe, you can do that too.
I have an ASP.NET Web application that was successfully running on Linux with the help of dnx-mono NuGet package. I used to publish it by using dnx publish tool and run it with the command:
/opt/dnx-mono.1.0.0-rc1-update1/bin/dnx --appbase /path/to/json Microsoft.Dnx.ApplicationHost kestrel
Since dnx is obsolete, I want to get rid of it and migrate to .NET Core, but it does not work anymore on Linux.
Important: I cannot make my application .NET Core app because it uses some libraries (like MySQL.Data) that are still not available for .NET Core. Therefore, I create ASP.NET Core Web Application (notice .NET Framework):
I migrated the whole application and run it successfully on Windows, but my target is Linux. No more dnx publish, no problem - there is dotnet publish which works well and produces binaries. What now? Dnx-mono package does not have a "dotnet-something" successor, and using dotnet command with published binaries produced errors that I was not able to resolve (The library 'libhostpolicy.so' required to execute the application was not found), but I don't think that I should even use dotnet command with standalone binaries. Googling didn't help as most tutorials are focused around ASP.NET Web applications for .NET Core, not for .NET Framework. Version of Linux is Debian 8, dotnet command was obtained by following this guide. Any clue?
You cannot run an application on Linux that targets the full .Net Framework, it has to be Core only.
In previous versions of what is now .NET Core, using the dnx toolchain, it was possible to run an application straight from source code, without compiling to a DLL on disk. This capability was also present on Azure, allowing you to edit code on the server and have those changes reflected in the live site.
The new dotnet CLI run command seems to automatically create the familiar bin and obj folders with compiled DLLs in them, and the publish process from Visual Studio to Azure now no longer includes the C# source, just the DLL.
Is it no longer possible with the new CLI and other tools to run .NET Core code without creating a DLL on disk?
Short David Fowler response:
Dynamic compilation is gone in RC2. It only exists for views now. There are no plans to bring it back.
Why?
Architectural challenges and changes require to implement it on both .NET Framework and .NET Core. We did it with dnx and there were some problems (like some things being completely broken with in memory assemblies) that we chose to just avoid.