I have a .NET Framework project that requires running a built console application from a .NET Core project in the same solution.
Take the example file structure:
Test/bin/Debug/Test.exe
Service/bin/Debug/netcoreapp2.2/Service.dll
The current approach involves starting a new process, similar to the following:
dotnet run ../../../Service/bin/Debug/netcoreapp2.2/Service.dll
I am fairly new to .NET, and so unsure if the following ideas are possible:
Modifying the path when running the Test application so that I can start the Service process with dotnet run Service.dll.
Getting the Test project to copy the Service build files into the Test build folder.
For bonus points, if/when the Framework project is upgraded to Core, is it possible to start a Core application process by using it in another application?
Edit:
For clarification, I'm hoping to avoid using that hard-coded relative path to build output folder, since it changes between Framework and Core and different versions of Core.
My hope is to find a built-in variable or functionality to get the build location of another project (even if I need to hard-code the Debug/Release part).
For example (excuse the pseudocode):
using Service;
var path = getPathToDebugBuildFolder(Service);
startProcess(Path.Join(path, "Service.dll"));
If you right click your project in Visual Studio you can define your Pre- and PostBuild Tasks (Build Events).
And yes.. if you are using .NET Core for both applications then you can Add a reference to your class library / console application and use the public types.
Related
Let us imagine that we have two projects:
AspNetRunnerProject – an ASP.NET 6 project which is capable of loading DLLs of classlibs and serves as a driver/executor of such classlibs.
ClassLibraryProject – a .netstandard 2.1 classlib project which uses AspNetRunnerProject's nuget as its driver
What I've been able to do so far is to publish ClassLibraryProject as a self-contained app. This way all the DLLs that are needed (any kind of NuGet package or .NET 6 runtime DLLs) are bundled inside a common folder and the app can be executed with dotnet AspNetRunnerProject.dll. This way the driver project loads the classlibs it needs and runs it all.
Is it possible to publish the ClassLibraryProject (which has a NuGet reference towards the AspNetRunnerProject) as a framework dependent deployment instead of self contained app so that it can still be run with dotnet AspNetRunnerProject.dll?
If I try to execute something like the last command I get the info that "AspNetRunnerProject.deps.json" file does not exist, because the file that exists is actually "ClassLibraryProject.deps.json"?
Simple copying of this file to desired name does not solve the issue.
After researching for a few days I came to the following conclusions:
Find the ClassLibraryProject.runtimeconfig.json file in the published artifacts and rename it to AspNetRunnerProject.runtimeconfig.json
Execute the app with dotnet AspNetRunnerProject.dll
Alternatively it is possible to have a global appname.runtimeconfig.json file which could be used across multiple such projects.
For more info check https://learn.microsoft.com/en-us/dotnet/core/runtime-config/#runtimeconfigjson
I recently took over a automation project that was written in .NetCore 3.1 using XUnit/Selenium. The Project that houses the code is a console application, not a class library so DLL of the tests are not created. I've had experience getting JAVA Maven based into Jenkins and running each tests a a standalone build in Jenkins but with this C# version, I am not sure how to proceed.
All of their automation is in one Project of the solution, broken down to cs files with a Class in each one hold all the FACT/THEORY Tests.
With .Net Framework, you can target the dll of each test to run it but in this case, I cannot see how to do this without the DLL. They essentially want to target the test Class in each file and run it as a build in Jenkins.
Is this even possible or do we need to convert it to a Class Library to get it to work in Jenkins? The company does NOT want to change it to a Class Library if that can be done.
I know that they will need to install MSTest and the plugin Active Choice Parameter to target their appsettings.json file as well.
Try to change <OutputType>Library</OutputType> to your test project .cproj file
My example for net5.0
I am trying to build an system in C# for all modules which has a both a web site and a GUI interface. I have created two projects in the same solution. The two modules will need to talk to each. That is why I am putting them together. Maybe it is not necessary for them to be in the same solution but both need to run at the same time during testing and deployment. Presently when have compiled both modules but they are also using Entity Framework core. I have just started the web part and it cannot add the first migration. It complains that
Severity Code Description Project File Line Suppression State
Error Project '..\opencreditfederation2_23_web\opencreditfederation2_23_web.csproj' targets 'netcoreapp3.1'. It cannot be referenced by a project that targets '.NETFramework,Version=v4.7.2'. opencreditfederation2_23
Now when I try to get these things matched I am stuck because the web application only offers versions of netcoreapp and the GUI app only offers .NETFramework items. Is there a way round this I should I been taking a different approach altogether?
When I try to match them up this is what I see:
enter image description here
I have a stateless .Net Core services running in Service Fabric. In my services, I reference a class library that targets .Net Framework 4.7.1. I deploy the application via VSTS and one of the build steps updates the app version for services with changes.
https://learn.microsoft.com/en-us/vsts/build-release/tasks/utility/service-fabric-versioning
Everything works fine except that changes are always detected for the class library's dll-file. Even though I haven't changed anything in the code library! This causes the build step to bump the version of every single service. Not just services that actually has updates.
The logs looks like bellow. 'MyClassLibrary.dll' is a .Net Framework Class Library that I haven't touched the code in.
2018-03-12T11:39:51.1989307Z Searching service 'MyServicePkg' for
changes...
2018-03-12T11:39:51.2247570Z Searching package 'Code' for changes...
2018-03-12T11:39:51.9878149Z The file 'MyClassLibrary.dll' has
changed.
2018-03-12T11:39:54.3850926Z Updated package 'MyServicePkg\Code'
from version '1.0.0' to '1.0.1'.
I'm aware that the check for changes in the code package is binary comparison. So the binary obviously change when the project is compiled. However, I don't know why. I also have code libraries that targets .Net Standard 2.0 and they don't cause this issue as changes are only detected when I actually have touched the code.
I'm also aware that it is possible to manually omit files that shouldn't update from the application package https://stackoverflow.com/a/34886586 However, that is not an option since the deployment chain is automated.
So I have the following questions:
What causes the binary for a .Net Framework class library to change?
In what way does it differ from a .Net Standard class library?
How do I work around it so my services only updates when I make real changes? Port from .Net Framework to .Net Standard?
Some insight in the matter is greatly appreciated.
By default, the compiler will create different outputs even if you made no changes. Use the deterministic compiler flag to ensure builds with the same inputs produce the same outputs.
So, you need to specify /p:Deterministic=true argument in MSBuild Arguments.
The simple way is using Azure Service Fabric Application build template: Create a new build definition > Select Azure Service Fabric Application template, then you will find, there is /p:Deterministic=true /p:PathMap=$(Agent.BuildDirectory)=C:\ in MSBuild Arguments of Visual Studio Build task.
I've created a simple .NET core console app targeting .NET Core Framework 1.1. When I build it, it creates an assembly file named DotNetCoreConsoleApp.dll in the \bin\debug folder. So there is nothing that I can double click and run directly but interestingly when I start debugging the project by pressing F5 then Visual Studio is able to launch a process.
Project configuration of my project is as below:
How windows will be able to launch such an application process without any exe file? I understand that Windows only understands a file as starting point of a process if it contains PE header.
There is no exe file.
From msdn:
"Short answer, there isn’t one. When you compile your .NET Core console application for example, you get a DLL. Then you execute it using the DOTNET command from the .NET Core SDK found here."
From a different answer on stackoverflow (Visual Studio 2017 missing exe file):
You have two options:
If you want an EXE, you need to target the .NET Framework.
If you don't want to change your code, then you need to install .NET Core on the server and run dotnet pathToDll on a command line
https://blogs.msdn.microsoft.com/benjaminperkins/2017/03/07/net-core-application-where-is-my-exe-how-to-publish/