I had 2 projects in my solution. One WPF frontend and one C# library backend. This worked fine for month, but now I decided that a part of the backend has become complicated enough that I would split it off into it's own, third project.
So now I have 3 projects: 1 with most of the backend code that depends on nothing, 1 other backend code that depends on the first for interfaces, and 1 frontend that depends on the other 2 projects.
There were some namespace changes that I had to fix throughout the code, but else it's a straight forward change. Or so I would think. Because now my frontend suddenly has a requirement for Microsoft.Xaml.Behaviors that was not there before I split the projects (the error tells me it's required for the Xaml triggers that worked fine before).
I tried around adding references to the backend projects thinking that they may be required for some inheritance reason, but that didn't change anything. Only when I imported the Microsoft.Xaml.Behavior.WPF Nuget package to the frontend was the reference resolved.
The weird thing is that I have 0 frontend changes. I can check out the previous commit and the requirement is gone. All that is changes for the frontend are some namespaces and the added reference to the new project.
Where does the requirement suddenly come from?
Microsoft dropped support for System.Windows.Interactivity & Microsoft.Expression.Interactions in .NET 4.8. The functionality in these assemblies was replaced with a NuGet package: Microsoft.Xaml.Behaviors.Wpf.
Most likely, you recently moved to .NET 4.8.
Referencing the NuGet package: Microsoft.Xaml.Behaviors.Wpf was the right course of action.
Here's a blog post that talks about the issue:
https://devblogs.microsoft.com/dotnet/open-sourcing-xaml-behaviors-for-wpf/
Related
I am following a tutorial (this one in particular https://www.twilio.com/docs/usage/tutorials/how-to-secure-your-csharp-aspnet-web-api-app-by-validating-incoming-twilio-requests) in order to create an attribute for securing my Web API webhook. I am using .NET 6 preview 7 and it seems to me that in the tutorial they are using somewhat outdated libraries (correct me if I'm wrong), such as Microsoft.AspNet.WebApi.Core and System.Web.Http. I added these libraries to my project and after several hours I got it to work and my endpoint is seemingly secured. Now, as mentioned I added the Microsoft.AspNet.WebApi.Core library as a reference and Visual Studio 2022 even gives me an warning saying it might not be able to fetch the correct version of it due to version mismatching.
My question is: can this outdated library (or dependencies) interfere with my other .NET 6 API's/Web API Controllers and web infrastructure in ASP.NET Core? Typically to load other code, making me unable to leverage new functionalities, performance boosts and other improvements of .NET 6. There are a lot of DI going on and I feel like I do not have a full understanding of how everything is loaded and which libraries are actually used when I deploy my app to IIS. Ideally I would like to port this attribute class to use the latest .NET 6 libs but many of these objects and properties are handled differently in the newer libraries as I understood.
Thanks Daniel A. White for the help. My problem was that my endpoint is hosted on sub path and therefore the RequestRawUrl method in the example fetched slightly wrong URL.
Using: .net core mvc c#
I have a solution which has a .net mvc core web app & one class library. There is a shared project (class library) that I want to this solution
which is a part of different project (different solution as well).
All of these projects are stored in our local GIT repository.
If I add the external project as project dependency in my existing project then there would be 2 copies of the external project that we have to
maintain. If some developer updates external project how does the change propogates to other projects using it.
And there could be that some developer updates the external project when under its local solution which we want to prevent. Since all are in GIT
is it possible somehow to make dependency related so that any change in external is known to others.
So basically how can we prevent anyone to make local updates to the external project but also make sure any updates to external project are available to
any other project using them.
There are several approaches that you can use to achieve this.
Quick: Reference project in two solutions
The quickest is to reference the shared project from both solutions. This way, you can use it in both projects and the changes are propagated to the other solution because you are basically working on the same files. However, a huge drawback of this approach is that if you make changes in solution A that are not compatible with solution B (e.g. removing a method that is used in solution B), you will only find out when working on solution B.
Easy: Single solution
To fix this, you could merge the solutions into a single one that contains the shared proect and also the other projects from solutions A & B. This way, you still get the convenience of project references in a solution. In addition, you are notified about breaking changes immediately if you build the complete solution. If this approach is viable for you in terms of solution size and team structure, I'd favor this approach. As you already share a single Git repository, I think this approach is well worth considering.
Nuget Package
If you want to keep the solutions strictly separated, you'd need to follow a more complex procedure. You could for instance move the shared project into a solution of its own and create a Nuget package with a clear build and versioning strategy. You can host the Nuget package on a package feed (e.g. on Visual Studio Team Services). Solutions A and B can then reference the Nuget package from the feed and also update it if a new version becomes available.
Here the official documentation to create nuget package with nuspec or csproj
Create .NET Standard 2.0 packages with Visual Studio 2017 [CSPROJ]
Creating NuGet packages [NUSPEC]
Background
I am working on a reasonably large legacy ASP.NET MVC solution.
Currently all of the code resides in just two projects (one containing model first C# generated code, the other containing the rest of the application).
Problem
I've added 2 projects to the solution - one for unit tests & one containing some code to be used as a service by the web application.
When I reference the service project from the main project there's a yellow warning sign by the reference.
As I said this is a legacy project with code all over the place & I'm not sure why this is happening.
I've tried Googling for a solution but haven't been able to find anything that gives some clues to this problem...
Note: There are just two classes in the service project
Here's a picture of the warning:
Make sure that both projects are set to the same version of the .NET Framework.
For example if your Main project targets to .NET Framework 4.0 and your Services project targets to .NET Framework 4.5.2, you can expect some compatibility issues.
I am having a bit of trouble. I have no idea what question title is appropiate in this case, feel free to edit it, if you have something better in mind.
So, basically this is the current situation:
Currently I have four projects (not the real names, but the architecture is identical):
Client (the main client logic)
Server.Main (the main server logic)
Server.Extensions (some functions for the server, e.g. helpers etc. can be used standalone, shouldn't rely on something from Server.Main)
Shared (shared code between client & server)
For each of the projects I create a Nuget-Package and upload it to my online repository. This repository is private for now and only for development purposes.
Here is a summary, what project uses what Nuget-packages:
Client uses the Nuget Package of Shared.
Server.Main uses the Nuget Package of Shared & Server Extensions.
Server.Extensions uses the Nuget Package of Shared.
This works fine for me at the moment... I can easily update my repository for testing purposes and use the freshly updated version of my package.
But here comes the problem:
I would like to share my project with other people now (e.g. the GitHub community). But when they have gotten the projects, they don't have any access to my private repository and the nuget package manager will not find the packages.
Further more there is another problem with my architecture: When they will fix something, e.g. in Shared, they wouldn't be able to test the changes, because the Client & Server would always use the Nuget package from the repository and not the fixed/changed local code.
And I thought about referencing the Shared project directly in all other three projects. Would that mean, that whenever I update Shared, I have update all other three projects aswell?
I think, my whole Nuget architecture is wrong. But I don't know how to do it correctly / in any better way. Does anyone have a better approach for me?
I wouldn't say this is necessarily wrong. If someone is trying to consume and work on your solution, P2P (project to project) references are probably the best since there is minimum overhead and there is a higher probability of catching issues early on during build and subsequent debugging sessions.
You can still easily create NuGet packages for all three during build and consume them in lets say a integration test by either packing them in a post build step or using tools like NuProj.
I'm trying to add ASP.net Identity 2.1 to an MVC 5 project that currently uses the (surprisingly quickly forgotten and replaced) universal membership providers.
This is rather a large number of changes because it requires getting OWIN up and running too... in short, it's a helluvalot of nuget packages and some code changes.
I've got a working MVC project built from nuget package Microsoft.AspNet.Identity.Samples. I'm going to crib almost everything from this project and transplant it into my target project (in a different solution).
I rather don't fancy switching between windows, checking version numbers and selecting packages or issuing individual 'Install-Package' commands in the package-manager console.
What's the quickest route to copy all the installed nuget packages from one project to another given that they exist in different solutions?