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
Related
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.
I'm in the process of migrating my solution from .NET Standard (targeting .NET Framework 4.7.1) to .NET Core (targeting netcoreapp2.1). My solution consists of 12 projects, two of which are web API projects that both need to run simultaneously.
I changed the targets in all my solution's .csproj from "net471" to "netcoreapp2.1". In a few cases I also had to update the APIs in code. There are still several warnings I'm dealing with regarding potential package incompatibility.
However my main problem is the following error:
Error CS0017 Program has more than one entry point defined. Compile with /main to specify the type that contains the entry point. Foo.Api D:\Code\Product\Foo\src\Foo.Api\Program.cs 9 Active
My solution has two startup projects, as it consists of two APIs that are related but separate. I don't want to specify one as the main as I need them both to start up when starting my solution, and under .NET Framework this was no problem.
Is it possible to have these projects start up together?
Note that if I add <StartupObject>Foo.Api.Program</StartupObject> to one of my API projects as described here, I can successfully get that project to start. I think this is equivalent to compiling with /main. I cannot, however, get the other API project to start the same way. Instead, I can dotnet run that project and have them both running. However, the compile time error needs to be resolved for it to get through our release pipeline.
There are definitely only these two Main methods in my solution. Here is the results of a find on void Main:
My problem is resolved, but I am still not sure what caused it.
I was referencing a few packages that gave the following warning:
Warning NU1701 Package 'CacheManager.SystemRuntimeCaching 1.1.2' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETCoreApp,Version=v2.1'. This package may not be fully compatible with your project.
I upgraded most of them, with the exception above, and I was able to run and debug both startup projects simultaneously without error. My guess is there was some kind of conflict with one of these packages.
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 am working on a Windows Service Application. I have several classes in the project and I am trying to put these classes into a ClassLibrary so I can use those classes in the Service App Project, and also in a Console Application Project, so I can run the console version and step through the code. I don't want to re-invent the wheel here...
I have created a Class Library project, and I am having trouble updating the projects in this Solution to use these classes. In fact, when I moved all my classes into the Class Library project, they are all now throwing errors saying, "System" has no member "Data"! My A$$ it doesn't! Pulling my hair out.
Obviously, I have done something wrong. I've been programming since before there WAS a Visual Studio IDE, but this is SEEMING way more complicated than it should be.
Now my Service project cannot reference my Class Library project because the library doesn't have a .dll or .exe extension? I actually have to specify this somewhere, WhereTF do I do this? Isn't this the default behavior of a ClassLibrary? OMG! I just finished an iOS application, and NEVER thought that would be EASIER than a C# app! I did this in VS2010 easily, is 2015 really different?
It should take me no more than 30 minutes to move files from one project in a solution to it's own project, and then add a reference to that new project in the old one. Giving MS a MegaMindWedgie right now..
Don't need portability with RT hardware, just want 32-bit/64-bit computer apps.
All 3 projects are using the same namespace. I can't seem to add any references to the ClassLibrary project like I can in the Service project. It's blank. The only reference available to the Class Library project is .NETStandard,Version=v1.6
HELP...
It looks like you have created .NET Core class library. You can determine this based on the extension of the project file: *.csproj has been used with classic .NET framework projects, and *.xproj was introduced for .NET Core. Most probably, you don't need a .NET Core class library. So, your problem will go away if you create .NET Framework Class Library project.
POSSIBLY POINTLESS BACKSTORY
In an effort to get out of NuGet hell (formerly dependency hell) my team has decided to switch to considerably larger solutions focused on our major divisions in the company. In the past we would have a core DLL that contained the most common code for a particular system and multiple solutions that pulled that DLL in through NuGet. This resulted in a lot of packages, and even more solutions, which ultimately meant a highly fractured collection of code for each division.
Our new approach is to move towards using a large comprehensive core library that gets exposed through a Web API. We also plan to serve up the core DLL through a NuGet package for situations where Web API performance is not suitable.
A basic solution will have 3 projects: Core, API, and Wrapper. The Wrapper project provides methods for accessing the API through simple methods rather than re-writing all the Web API calls in our apps that will use it. More complex solutions will have additional projects such as Windows services and console apps to run as scheduled tasks.
The 3 basic projects will all share the same version number because they're tightly coupled. The problem arises when including other projects that should not use the same version number in their builds.
THE REAL QUESTION
I have a solution with 4 projects: A, B, C, and D, A-C are always updated together and share the same version number. D is a service project that has its own logic in it that can change independently of the other projects, and therefore should have its own version numbering. However, to avoid confusion, D should be deployed with the correctly versioned DLLs from A-C. (Meaning that if D is on 2.0.0, and A-C are 1.0.0, the DLLs from A-C in the install directory should show 1.0.0 in their details.)
With that in mind, is there a way in TeamCity to build and control the version numbering so that the projects that need to be unique can be, and still reference the correct dependencies?
Notes:
I know that the easiest solution is to simply move the special projects to their own solutions and reference the core DLL, but that's part of what we're trying to get away from.
We want to be able to have proper build numbers on our finished files, as well as have tags in Git from successful builds.
As far as I can tell, the AssemblyInfo Patcher feature in TeamCity can only overwrite the whole version. If it could simply overwrite the build number then I could control version numbers right in my source code.
Well you are right AssemblyInfo Patcher won't help in this case, as it updates all assemblyinfo files or global assembly info file. There is no straight forward way I am afraid but I think you could try something like below:
Rather than building the solution, build individual projects using .csproj files, i.e. break compilation into 4 steps one for each project (A-D).
Use AssemblyInfo patcher for A-C projects so they can simply use Teamcity version %build.number%.
Add a pre-build event to D csproj to update its assemblyinfo information. You'll need to define a variable in teamcity for first 3 bits of its version say DVersion(1.0.0), the last part of it can come from %build.counter% variable. Pass this version (%DVersion%.%build.counter%) as a parameter to D csproj file build step.
Finally update teamcity build number by writing logs to something like ##teamcity[buildNumber '%build.number%-%DVersion%']