I've got app 2 solutions (.NET C#) which each share a portable class library (a seperate solution). The app solutions reference the PCL as a project, not by DLL.
What's the best way to deal with this scenario with source control? The portable class library may change for one version of one of the app solutions but not immediately for the other.
I'm not tied to any source control at the moment, I was attempting to do this with TFS but have workspace issues on the portable class library. I'm open for a better suggestion such as Mercurial or Git!
If the updates of your PTL should affect only one application, you can create branches (available with most source controls softwares).
If you have a branch for each application; updates will be visible only in this branch. Then you can use merge tools to update the other one.
Branches are also available in TFS : http://msdn.microsoft.com/en-us/library/ms181425.aspx
For strategies : Branching Strategies
On way is to keep the shared library in a separate area of the source control system. Each project that depends on the shared library will then have to create a branch of the shared library that's specific to the project.
Development is isolated on the branch but you can merge changes on the project branch back to the main branch of the shared library. Other projects that already have branches of the shared library can decide if they want to merge changes to the main branch into their own branch.
You will have to perform some merging when the shared library is updated but using this setup you ensure that each project is isolated from changes performed in the other projects. Each project can decide when they want to upgrade to a newer version of the shared library.
Related
I have just learned and created a shared project in visual studio 2017. I have noticed that the shared project did not have the "Reference" to refer to other resources (other projects, class library, …). I even take a look at the .shproj file and saw that it only Import the class I have created inside the shared project.
My problem is that if I want to create an add-in app, I need use the class library to call the necessary API that is exposed by the origin software.
How can I reference/add other project/ class library (or resources in general) to my shared project? Or is that even possible at all?
Part of my problem is also described here reference to a shared project from other shared project
But I need a more general solution. Thank you all for your help.
Long story short: shared projects don't, and realistically can't work that way.
In Visual Studio a shared project is just a container for files - source code, resources, etc - that you can add into other projects. This can be useful in some cases when you want to have the same code (and so on) in multiple projects without putting that code into a library.
Shared projects do not have references, do not have NuGet packages or anything, just the files that they contain. They don't even have the configuration data required to compile any source files they contain, and the compiler won't do much validation of the contents if the shared project isn't included into a full project of some sort.
And since the shared project doesn't have any way of specifying references or packages then you will need to add those references and packages to every project that links to the shared project. The compiler will tell you pretty quick if you miss one.
While it would be nice to have references in shared projects, it turns out to be much less simple than you might think. The same shared project can be included in projects that target different frameworks, platforms and architectures. Let's say you're building some code that will run on iOS, Mono, Windows .NET Framework and .NET Core, with specific code for each target and some shared code. If you try to add a NuGet dependency to the shared project it's going to blow up in your face on at least one of those. Same with most of the references. Add all the references you need for .NET Core and suddenly the other projects don't compile.
You need to add the reference in the project which consumes the shared project.
As an example, let's say you have "Project A" which references "Shared Project B", and you need to use Newtonsoft.Json in "Shared Project B". Since you can't add a reference to the shared project, you install the Newtonsoft Nuget package to Project A and your code in "Shared Project B" will automagically compile.
After searching quite a bit, I seem to be unable to find an answer to my problem. Usually, I find that means it is a non existent or incorrect approach, but I think it worth it to have an answer floating around on the internet nonetheless.
Essentially, we have 4 applications referencing 5 different "source" projects. So the scenario is, when we add a 5th application (for example), we will need to create project references to the other 5 different projects, as the application requires their output.
Its not a difficult task because the amount of projects is small, but it got us thinking. What if you could create a single project, maybe called Libs or something, reference all 5 projects in that project, and then the applications must only reference Libs. The idea seems cool, but I don't know if it will work because when you create a project reference, it points to Libs single output libs.dll.
So to actually ask a question, is this possible, and if so, how can it be done? Currently, having Libs reference the other "source" projects, and then having the applications reference the Lib project does not work, as it says there are missing assemblies.
And just to go over how this was created. The 5 source projects reside in a couple different solutions, so the only tedious part of this approach is "add existing project" at the initial start of the application's solution.
The way we manage this kind of thing in my organisation is to make a NuGet package for each of these shared "source" projects (e.g. in our case we have an error logging library, an XML utils library, a bespoke HTTP client, and others). These are published to our private NuGet feed URL (hosted on Azure DevOps, but you can just use a standard Windows fileshare if necessary) for our developers to use in their applications.
This has some clear advantages over your approach:
1) Dependencies - this seems most relevant to your question. If the project you built the NuGet package from itself depends on any other NuGet packages (either publicly available ones, or others from our private feed) then when someone installs that package in their project it will automatically install all the other packages it depends on.
So in your case you could create a shell "libs" package which doesn't deliver any content itself, but has dependencies on all your other packages, causing them to be installed automatically. In our case we have several cases of dependency (e.g. a "base" error logging package which is relied on by error handling modules which are tailored to different app types, e.g. MVC, Web API, Windows Services), and it works very well.
2) Updates and maintenance. In your scenario if you make a breaking change to one of your "source" projects, then, because you have a direct project reference declared in Visual Studio, any project which references the source one will have to make related changes to cope with the updates to the source project, before you can re-compile it and do whatever feature changes you're trying to achieve. This could be a pain, and be an untimely problem, especially in the case of major updates. However if instead you install a NuGet package containing that functionality, the developer of the application can choose if and when to install an updated version of the package.
There are other minor benefits as well which I won't go into, but there are some very good reasons why almost all major programming languages now provide similar "package" and "feed" functionality as a way of managing dependency on external projects and libraries. Your approach is, I feel, outdated and naive, resulting in the issue you've described and the potential for other irritations as well.
I would like to know how I can share c# source codes between two (or more) .NET Core projects (commandline projects!).
As far as I understand, I can not link to source files in different directories in xproj/project.json based projects. I noticed that it now seems to be recommended to create nuget packages for everything. But is it really necessary for me to setup a private repository and create a nuget package only to be able to share some common source units?
VS2015 contains a template for .NET Core library which may be suitable for building a shared lib. Is it possible to link this lib to a project without a nuget package?
.NET Core Library is an excellent solution for you.
Do it the same way as in standard C# solution - just create the project and reference this project or add a reference to DLL file.
You don't need to use a Nuget, for your own purpose. Nuget packages could be useful to distribute your dll outside.
Clarification:
I miss one point - I'm using VS2015, but I have included Class Library project in my solution, and I'm referencing by project, not by DLL file, and this works fine in ASP.Net Core.
I also have a different project, where referencing DLL file directly working fine, but this is the previous version of ASP.NET app (not Core) - seems NET Core doesn't support this way like as the previous version (yet?).
Sorry for confusing you, sometimes it's too many technologies ;)
So could you just include ClassLibrary project into solution with your project and refer it as a project?
I have achieved this by using source control to branch from my commonly used projects in each new solution, and again merging back to the master branch if I make any changes.
Alternatively, baring in mind that NuGet is only an archived collection of files, you could keep this NuGet package locally, or even create a Template for Visual Studio that has the common libraries by default.
There are a wide range of possibilities that are down to your preference, and current environment state (I.E: Able to setup Source Control, or a package repository).
I have a Class Library that i need to reference in different solutions, and this library has dependencies to other DLLs (itextsharp in this case).
If i want to create two applications using this same DLL (that is created in its own solution), how do i deploy my DLL so it can be used by these?
Do i include itextsharp when i deploy my DLL, or do i state that it is dependant on itextsharp somehow ?
Basically im looking for best practices, or "the way to do it" :)
Thanks!
If your application is dependant on the itextsharp library and the library license agreement allows redistribution of their DLLs then you should include them in your deployment.
You should leave your application in a 100% working state after deployment.
My SAAS company has two C#.NET products, call them Application Alpha and Application Beta. Both of them reference some libraries that we can call Core.
At the moment, the codebase is monolithic, stored in a single SVN repository with a single .NET solution, and we're trying to make it more modular/componentized. We've split off into separate repositories for the two applications and the core library, but we're now running into the following problem:
Alpha and Beta must reference Core, but we're trying to avoid having a direct code reference because then we're practically back to square one: you would need to check out and co-locate all repositories. So how should we go about referencing assemblies between these components?
Each component could have a directory containing DLLs from the other components that need to be referenced, stored in SVN, but this would mean extra effort any time Core is updated to push out the new DLLs to Alpha and Beta.
Or we could store the DLLs in a central SVN'd location (and/or in the GAC), but that would mean extra effort any time Core is updated for everyone else to pull the new DLLs.
Is there a third option that we're overlooking?
I have something similar in which I have 5 applications utilizing a series of web controls I built. The controls are compiled into a series of DLLs for modularization and the applications that utilize them live on separate servers.
What I do is utilize VS2008's build utility to execute a batch file that copys the compiled (updated) DLLs to the production servers when a Release Build executes.
You do this by going to the project that builds into the DLL (or DLLs) and right click on that project and goto Properties. Then you goto the BUILD EVENTS tab. There you see Pre-Compile command line and Post-Compile command line textboxes.
Therefore your release builds can be fully automated and you never have to worry about DLL hell-like differences between versions of your production DLLs.
Hope this helps,
JP
you could have your rebuild script for Alpha and betat create artifacts (namely build core) and place the result of the core build at a specific location referencing that location.
You could use SVN:externals. It was designed for this type of scenario.
If you want to avoid that, these are probably your better options. I'd avoid putting the files in the GAC, though, unless your core project is very stable, and not changing very often. Having the DLLs local provides much more flexibility.
Each component could have a directory containing DLLs from the other components that need to be referenced, stored in SVN, but this would mean extra effort any time Core is updated to push out the new DLLs to Alpha and Beta.
This could be handled fairly easily with a good build system. This approach has some disadvantages (ie: exectuable depdenencies in the build system), but has some advantages, including allowing each dependent project to have different versions as needed, etc.