Microsoft says it's platform neutral these days, so I'm trying to build on Mac and Linux only with VS Code and deploy to Azure. Why? It's mainly to prove that I can.
Our project has several parts which include a couple of different websites, a Web API, er API and a few other bits. On my Mac I've built a .Net Core Class Library with a load of objects in. Command line, dotnet build, DLL out, no problem.
I want to put that DLL on the Linux machine where the MVC website is being built - the objects forming the models part of that site hopefully. I cannot figure out how to get the website project to reference my DLL and use the objects.
I had assumed I copy it to the other machine, place it in the bin folder of the site being developed and reference it in the Dependencies section of the site's project.json. Nope. I saw a few articles that said .Net Core only works with NuGet and it had to be a package. Is that really true?
I've found and read (if not entirely understood) everything you could imagine on sharing between .net core and .net framework. This is a core-only project so not applicable. Frankly I'm lost, and something called .Net Standard has just rolled into my field of vision.
So instead of copying the DLL, use dotnet pack to build a nuget package on your Mac, and copy that to your Linux machine instead. Put it in a directory that you configure as a local nuget repository (no server or anything required) and you're away.
I agree it's not as straightforward as a reference to a DLL, but it's not too bad. Note that you'll need to version the package appropriately, so that the tool system can detect when it's changed.
Related
My goal is to create a build output that acts as portable version of my application, containing the non-framework dependencies (nuget + projects) directly as dlls.
This demonstrates the solution and the four projects contained:
You can see the libraries are .net standard 2.0 while a console app (to run / debug some code) is using .net framework 4.7.2 (because we have some .net framework apps in use around here). The arrows in the image show the references that have been set.
Parts of the the libraries (not console app) might be imported into MS sql server in the future; these imports usually pick up all dependencies from the same folder if available (which is the reason for a self-contained output).
Problem A: Running the code on linux/mono
Using jetbrains rider to open the solution, build + restore packages will work without problems.
Running the console app will work to some extend (e.g. loading data from SQL) until it fails when calling some code that makes use of BouncyCastle (dll not found exception).
Looking at the build output shows three .dll files of my lib-projects along with the .exe file of the console-app plus all the .pdb files AND additionally the System.Data.SqlClient.dll.
Seems that might be the reason my sql code worked.
Problem B: Running the code on win10, .net framework / core installed
Using VS / rider made no difference here, opened the solution, restored packages + build without problems. Running the console-app fails earlier than before: this time it was unable to find the Syste.Data.SqlClient.dll.
Checking the build folder shows my three lib-dlls and the .exe including the .pdb files, nothing else.
To my understanding, the files have to be either in GAC or inside the same folder for them to be found. It seems when a .net standard library dependency includes nuget-packages, something is having troubling either loading them into GAC or at least copying them to the build directory (which is outdated I guess).
So even if my approach (having a portable-ish / self-contained version of my app) might be uncommon or even stupid, I would have thought that just running this code on the dev-machine should work fine.
Problem C: Including dependencies in the build output
According to information I found here, the <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies> property can be used to have dependencies being copied to the build directory.
And while this seems to copy too many files (tried excluding some according to docs) it does indeed copy the .dll files for a complete package when building the ExchangeIntegration project (.net standard 2.0).
Looking into accomplishing the same for .net framework .csproj projects yielded mixed results. I was playing around with the copy-local setting and stumbled across similar problems when creating nuget packages and using .targets files but had no success.
About the specific libraries used
I'm more interested in learning the right concept to handle this, it's not really about whether or not it makes sense to import Newtonsoft.Json into MS sql server.
I feel I'm fundamentally missing something; maybe the output type library is not correct for my goal or maybe I'm mixing problematic .net versions, although I did a quick check and it seems ok.
How can I get a .net framework (console-app) build that contains all non-framework dependencies (e.g. nuget) AND an separate .net standard (library) build, that also contains all non-framework dependencies?
EDIT: Adding all nuget packages to the top tier project (console-app in my example) seems to work around the problem, code executes without problems. I'm still waiting for a proper solution.
EDIT2: Added mono/msbuild version used under arch: 16.4
I am doing maintenance work on a VS2010 C# project built against .net v3.5.
I recently changed the project Target Framework properties to the latest version listed (v4) - due to an expectation of using a version of .net that is actually included in Win10 by default - and rebuilt without any apparent issues.
Unfortunately the embedded dependency in the generated .exe is still for .net v2.0.50727 (which is what is reported for v3.5 AFAIK) and the target machine (a clean install of Win10) is asking to install .net 3.5.
Using MS VS2010 v10.0.40219.1 SP1Rel.
Unfortunately upgrading the build tools isn't an option (building the program with VS2015 works just fine).
I have gone googling but don't seem to have found any similar reports.
Based on some of the comments already posted, I seem to have not made myself entirely clear - hopefully the following will help.
1) the intention/requirement is to be able to install this app on a clean install of Win10 without needing any further downloads. (installing .net 3.5 is easy to do, just not what is wanted)
2) the ultimate build environment for this is automated, visualized and not in my control and therefore upgrading the tool chain is a major pain that I'd like to avoid if possible.
3) AFAIK there are no third party libraries involved. All of the listed references (dll's) are v4.0.30319.
4) this is a XAML-based development, one part of three projects in the solution - the other entries are the installer and a C# custom installation library. As far as I can tell everything is set for .net v4.
Unfortunately the embedded dependency in the generated .exe is still for .net v2.0.50727 (which is what is reported for v3.5 AFAIK) and the target machine (a clean install of Win10) is asking to install .net 3.5
So there is some dependency in your project that targets that version of .NET. It could just be that you need to Build > Clean Solution and with a Build > Rebuild Solution the problem is solved.
Otherwise, assuming some library does require some .NET 3.x library, the installation request is entirely correct. Windows 10 does not have an option for installing .NET 2.0 and another for installing .NET 3.5. If you search for Turn Windows features on or off you will see this:
Any dependency on a .NET 2.x-3.x library will trigger the activation/installation of the first feature in the dialog.
As far as I can see, you have 2 options:
Move everything to a framework supported by Microsoft, most preferably .NET 4.7.2 given support and security.
Deal with the installation process and understand that Microsoft does not install these versions of .NET in purpose. You can, however, add these installers as a prerequisite and even bundle them with your installation, but that won't help much.
Thanks to all who have tried to help me!
The issue has been resolved.
There appear to have been two causes for this issue and my confusion:
it turns out that the blank install of Win10 that the testing was being performed on was not entirely clean - the pre-installed network drivers/utilities from intel also had a .Net v3.5 dependency...
one of the embedded resources in the project was effectively a uncompressed tar-ball containing a number of files; including an executable that had the dependency on .net v3.5 - this was a binary blob stored in svn so the content was had not been updated for several years (ie well before my involvement) ...
With both of these issues addressed it would appear that my problem is solved, so once again thank you for your feedback, suggestions and patience,
PeterT :->
Is there a possibility to publish .NET Core Console Application as single file (no matter if it's EXE or DLL)?
I am using .NET Core 1.1 but I am elastic to port my project to another version.
At the moment, this is not possible because:
portable applications still need at least a runtimeconfig.json to tell the host (dotnet / dotnet.exe) which shared runtime to use. Even if you IL-Merge all your managed code into a single dll, this file is still required. The host also expects a deps.json expressing the dependencies of the application.
self-contained applications rely on building a .dll + .deps.json and copying over content from runtime-specific NuGet packages. This also includes native libraries that are searched for by file name.
The CoreRT project aims to compile a .NET Core application to a single native binary using ahead-of-time compilation but is still in development.
I cannot find in the documentation a way to start a XSocket server without using the PlugIn Framework.
I have a very easy library which contains its own controllers (located in the library itself) and which references XSockets.
I don't really need the PlugIn Framework and it is disturbing me because my library is located in a binaries folder with a number of other components that I don't manage. The PlugIn Framework is not working properly in such a complex environment and I'm quite sure it has to be possible to get an instance of the server singleton (new() is not working) without having to use:
server = XSockets.Plugin.Framework.Composable.GetExport<IXSocketServerContainer>();
thanks for your help.
My guess is this.
You have a non .net assembly in your bin folder. In XSocket plugin framwork version 1.1 there was a bug throwing an exception when trying to load an non .net assembly.
This issue is fixed in 1.3 (current version) and upgrading to XSockets 3.0.3 should take care of this issue.
I have been recently trying to deploy a C# application on a computer that does not have .NET installed.
I know that there have been many questions around the same topic here on StackOverflow. Here are a few of them, of which I read the responses to all:
Packaging up the .net framework with a .net application deployment
Run a .net application without installing .net client profile?
Run C# windows application in windows XP without installing .NET Framework
So all of the responses to the above questions state that it is impossible without specific software, etc. One software mentioned was the Salamander .NET Linker. The only problem with that is that I cannot seem to be able to run the application after it has been processed by Salamender. I understand that this in itself is impossible, as it requires the .NET virtual machine to run. However, in the past, I have made Java applications and along with them, I shipped the entire JVM. Surprisingly, they still worked. So the reason why this is not a duplicate of the above questions is because my true question is:
What items of the .NET framework would I need to package? If I do manage to package all, would placing them in the same directory as the application I'm running allow the application to run?
I found one solution to this, the Microsoft .NET Redist Package. The only problem with this is that it has a GUI of its own. Aside from that, it would be a perfect fit. So, could anyone tell me one of two things:
Is there a command-line .NET package, and if so, where do I download it?
If there isn't, or it would be impractical to do so, approximately what directories would I need to copy from the .NET installations?
I understand that these files and directories are system specific, and that my .NET installation may not work on your computer, but if C# is like Java, then this should be achievable. Is it? Size is not a limitation, it does not matter to me whether or not the application and all its files is 1GB, or if it is only 1MB.
If in case there is no other solution, I used Dependency Walker to check all the dependencies of my program. If I were to package most of them, would my application, in theory, work?
For .NET, you really must just install the appropriate .NET framework. The .NET framework installation does include command line options to allow for silent installs, such as:
dotnetfx35.exe /q /norestart
For details on the command line options, see the options for 3.5 and for .NET 4.0.
That being said, most installation packages will handle these details for you as part of the installation. Using a decent installer will take care of this dependency automatically.
Depending on the pieces of the .NET Framework you need, you can use Mono. It supports shipping the runtime without installing just like you would a JVM, or you can statically link against the binaries to create a native executable .
If you are planning to deploy your application (and presuming the setup process doesn't need to be too complex), you can simply create a Setup project in Visual Studio and then bootstrap the prerequisites (.NET framework, and other stuff you think you might need).
You can follow the steps described in these MSDN articles:
How to create a Setup project in Visual Studio
How to add prerequisites to a Setup project
A walkthrough is given in this CodeProject article.
For more complex deployment scenarios (such as installing device drivers along your app, or better localization support), I would recommend looking into WiX (Windows Installer XML) toolset. It's a toolset that builds Windows installation packages, which you configure using XML files inside Visual Studio. WiX also supports various bootstrapping scenarios.
This page covers the differences between VS Setup projects, WiX, and InstallShield.