I have a C#/VB .Net Class Library which is used in multiple projects.
One of the issues we face is if a change is made to this Class Library it needs to be deployed to multiple projects.
As you can imagine, one project could be left out and this causes the application to stop working if the dll isn't the latest version. Sometimes this comes down to checking the version number of the dll and if it's not the correct/latest version it needs to be replaced.
The problem is sometimes the version is not incremented on the Class Library project which could mean for each of the project/applications the fix has been implemented but the version is now giving a false reading as it wasn't changed during development.
Is there a way to increment the Class Library version once development has been completed without relying on it to be done manually?
Is there an automatic way to increase/set this? We don't want it where it's increased every time we build, only once development is complete?
Any other better ways to tackle this?
I would suggest you to create a nugget package of your class library. and you can easily maintain the versioning. so if you want a few applications to use a particular version you use that if you want a few applications to use another version you can easily use it by updating to a particular version using NuGet package manager in visual studio.
Related
This is my first question. I have tried really hard to find a solution to my problem, but it seems to be a pretty specific collection of problems and I haven't found anything that works. I think I have narrowed down/identified my problem, but I don't know the solution or how to implement it correctly. I have tried to be detailed, but also concise. I don't have a strong coding theory background, just what I have learned online from MS documentation, Stack overflow, and other tutorial-like websites.
Background
In visual studio I wanted to create a class library that manages tables in a given database. It's part of a generic style API to handle implementations of repetitive database structures across projects. Because I wanted to create a generic class that I could use in various projects utilising various .NET frameworks, I decided to build the class using .NET standard 1.4. Because I needed to connect to MS SQL databases, I imported the System.Data.SqlClient namespace (an System.Data.Common) using NuGet.
I employed the use of a test MVC application in the solution and got some basic functions working in Visual Studio including opening the actual databases. Despite the recommendation not to, I referenced the compiled DLL from the release build rather than importing the reference as a project. I did this to mimic how I would be testing the class in my deploy environment. Everything here worked fine provided I added the reference to System.Data.SqlClient in the test application.
When testing the deployment however, things went awry. I was using an FTP connection to copy the files to the server. The server is running the .NET 4.5.2 framework. I kept getting a persistent error that the System.Data.SqlClient version 4.1 could not be found. I tried importing it into the project using NuGet and still had the problem. I was importing version 4.1, the earliest version (which is what I referenced in the class library). I also tried changing the reference in the class library to 4.4.2, the latest version, and importing that instead. Still had the same problem.
I then copied the code from the C# class from the class library and added it to a new .cs file in the FTP project- it compiled and ran without incident. I didn't need to import the System.Data.SqlClient in order to reference it, suggesting that a version of the namespace is already available on the server.
Problem/Question
This leads me to believe that there is a conflict where I'm trying to reference 2 different versions of System.Data.SqlClient within the FTP project.
As such, this leaves me to try and work out either:
How can I build a .NET standard class library that can use the latest installed version of System.Data.SqlClient in the target project (although, I fell like this is not really achievable given the way DLLs/versioning in general works)?
OR
How can I build a .NET standard class library that can use any of the currently available versions of System.Data.SqlClient (i.e. only use APIs that all current versions implement) and target the one already installed/referenced in the project that references it?
OR
How can I tell visual studio to include the referenced System.Data.SqlClient version used in my standard class library and only reference it for the purposes of running this library, with the rest of the project targeting whatever the other version may be?
OR
The otherwise correct way to manage this reference when it is not in the .NET standard library, but may be present in any given version in the application that references my library DLL.
Basically, I want to avoid having to write a new version of this class for every target framework if I don't have to.
End Note
I hope this question is of a good standard, I feel I have probably gone about something wrong in the implementation and that advice on the proper way to implement such a library would be of great help to myself and others in a similar situation.
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]
I'm using .NET standard libraries inside my desktop solution so I can share those libraries between my desktop and web solution. However, I'm seeing incremental build problems now. Has anyone else experienced this or managed to fix it?
I can see that the .NET standard libraries have some incremental build features in that if I build them on the command line using "dotnet build" it takes, for example, 1 second and then if I make a code change in that library and run again it takes 2 seconds. This goes back to 1 second if I run for a third time.
However, in pure .NET framework applications like a console app or wpf app, traditionally if you make no code change then inside visual studio it doesn't even attempt to build the project. It simply says "1 up-to-date". I'm seeing the .NET standard libraries always re-copied to the output directory and they also cause my entire WPF project to rebuild every time. After a while this starts to get annoying if every code change takes 5 seconds to build!
I have at least a partial answer for you. The issue of the binaries copying out every time is explained by Microsoft as essentially there is no support, update to a later target framework version.
At this point we don't do any smart trimming of the compat shims that come with the tooling so it ends up copying them all. If you (or your dependencies) don't rely on them it is safe to delete/not-deploy them but doing it blindly may break some of your dependencies.
And this is supposed to be fixed in 4.7.1
It's worth mentioning that with .NET Framework 4.7.1 and up you'll not have to deploy any extra files for .NET Standard. Today, that's already the case if you target Xamarin or .NET Core.
As for why it always copies, instead of doing so selectively as it should, I am unsure. I have scoured build logs and I believe that the files have not been properly added to the output list of a build target but it is difficult to diagnose. Visual Studio also has smart ways to entirely avoid invoking MSBuild, so logic in the MSBuild script to skip a target doesn't even have to run. Visual Studio is mostly a black box, but I suspect this logic is broken too, based on the behavior both you and I have observed.
This is a frustrating issue because there are still good reasons to target old versions of .NET Framework, for example if a library is distributed to a customer who may build against it using Visual Studio 2013, and cannot be expected to update.
We are developing a WPF application at work which has various "common" dependencies (Unity, Prism, etc.).
It's all fine when adding new projects and then setting up the NuGet package dependency per project but when it comes to upgrades, it's really painful as it means we have to go through each and every project, delete the old references and then refetch the latest packages from NuGet.
Today for instance, I was tasked with upgrading Prism from 5.0 to 6.0 (which has breaking changes anyway) and this meant, in addition to fixing all the namespace conflicts, etc. that I had to go through every project, delete the old references, add the new dependecies and rinse and repeat.
My question is, is there a smarter way to deal with this problem or is this the standard approach?
Many thanks in advance,
Update:
I am mostly concerned with "major" upgrades which don't show up on the package manager. Version 5.0 -> 6.0 upgrade would be treated as a major upgrade and hence, would not have an automatic update applied to it in the NuGet package manager.
I don't expect NuGet to be able to do this automatically for me since such upgrades may (and often do) include breaking changes but I would like to know if there's a way to do the major upgrades less painfully than deleting the references from the projects and the packages.config for every project and then re-adding them using NuGet. For a relatively large project, this is very time consuming and I was wondering if anyone had a better way of managing such dependencies.
If you use VS2013 like you say, you can manage ALL your NuGet packages by right-clicking on your Solution and selecting 'Manage NuGet Packages For Solution'. This brings up a dialog where you can view all packages installed for all projects in the solution and all packages that have updates available. When you do upgrade the packages, VS takes care of all the reference changes required. If the package has breaking changes, then you're still on the hook for fixing those.
Disclaimer: I've never worked on a WPF project/solution but for Web/Forms apps, NuGet packages are handled this way.
I can understand your pain because i had the similar problem like you, but there is no easy way. but certainly you need to break the process differently of your daily development and your dependency update roll-out.
for the project i worked on, I use the common repository path that shared among the solutions that you work on, and you need to delete all the solutions folder references in order to get a clean state.
For each solution you work on you need to modify the property group that point to the common target repository (i'm using relative path)
Once all the things setup, you can actually perform an update with a script(I'm using python run-time script)
you can actually look at setting up common nuget-packages-folder for reference updates for detail, but it seems like what you looking at for the automate process
I had a similar problem when trying to upgrade multiple packages with alpha channel issues in Xamarin Studio, which also does not have the niceties of VS 2015 NuGet manager. I ended up writing a very simple PowerShell script that I run multiple times a day.
#
# This script updates local ibGib NuGet packages for mobileGib Android app solution.
# For convenience in copy+paste in manager console:
# ../UpdateLocalNugetPackages.ps1
Update-Package commonGib
Update-Package ibGib
Update-Package languageGib.Biz
Etc.
I believe you could tailor your NuGet commands to fit your needs.
Also, just in case you aren't aware of it, you should definitely read the NuGet command line reference. I may be mistaken, but it sounds like your scenario is doable with the Update command.
Having a big solution containing tens of projects seems to get hard to maintain. I need to update packages in some of these projects, but I do not want to touch them in all projects.
Say for example, I want to update Entity Framework to version 6 in one class library project, but let the remaining projects keep using an older version. But since another project will need to call both projects using EF5 and EF6, will this even be possible?
Also, is it somehow possible to modularize class libraries so that they have their own dependencies, but do not make callers of these libraries dependent on the libraries dependencies? (Normally I need to add references to the dependency in both calling project, and in the project actually using the dependency directly). I pretty much want to make this class library a black box. The calling code shouldn't need to know what the black box does. And shouldn't need to add 10 different google api dll's to be able to use it.
Consider ILMerge?
ILMerge can combine multiple DLLs to a single library, meaning that you can package any dependancies with your DLL.
I can't give you usage advice however, I don't have firsthand experience.