I have a master solution with many projects inside, mostly class libraries for my other applications to use. Early in the project I needed to change a class name inside one of my libraries but VS would not let me refactor the name over all the projects, just the original library project. Is there a add-in that can help me do this or will i just have to use the rename command and change it from project to project?
You can also use resharper for doing this. http://www.jetbrains.com/resharper/
It has a more features than the VS refactor.
Related
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 have an independent solution with multiple projects including class libraries and control libraries. This solution and all its projects are under TFS source control.
I reference the output of one or more of these libraries in all new projects I develop. References are currently binary rather than project references.
The new projects are also always under source control and now I need to add debugging support for the libraries.
If I reference the library projects from them, the project file is modified and no longer works with the original library solution since source control providers for the library and referencee may be different.
Is there an easy way to accommodate this?
You should package the shared binaries, along with indexed PDB's, into a Nuget package. Nuget was specifically designed to solve these problems.
You can index your PDB's by running an indexing tool. TF Build can automatically index your PDB's.
Nope.
There are some strategies you can use, however. Easiest (possibly, but not in some cases) is to build the project you wish to debug, drop the binaries on top of the application that hosts them, and attach your debugger to the running application. This makes sure you have the correct version of the assembly under debug, but you might have to do unwanted things, such as making sure you're not targeting a specific version of the assembly
Which may be bad news for an assembly under development. It also requires lots of handiwork, which depending on where your application runs may require you run remote debugging, deal with issues transmitting dlls across untrusted networks, etc etc.
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.
I know there is someone who has post some questions like this. But my problem is a little different.
My program has two versions, one is for PC and the other one is for Windows Phone. In my case, they both use a same algorithm. I want to share the codes between two projects.
First, I tried to create a project containing these codes, then add them to my projects as a reference. But here is the problem, if i create a Windows Form Application project, I can't reference it in a WP project, and vice versa.
Second, I tried to add these codes to my projects as a link. But I have lots of files to share, I don't want add them one by one. And these shared files will mass my project directory.
What should I do?
You need to create a "Portable class Library" project and put your common code in there. it will create a dll. Reference it in other projects and it will work fine.
Using the Portable Class Library project, you can build portable
assemblies that work without modification on the .NET Framework,
Silverlight, Windows Phone 7, or Xbox 360 platforms. Without the
Portable Class Library project, you must target a single platform and
then manually rework the class library for other platforms. The
Portable Class Library project supports a subset of assemblies from
these platforms, and provides a Visual Studio template that makes it
possible to build assemblies that run without modification on these
platforms. - MSDN
sounds to me like you need to make a Class Library project. Create that and you can put in whatever code you want, then compile it to a dll, and reference it in any of your other projects.
I would like to customize an off-the-shelf software that has a Lite Edition and an Enterprise Edition. The features are almost the same so that my extended customizations can work for both, but I have to recompile for each version because they have different version assemblies.
Can someone help advise me on how maintain this? I am using Visual Studio 2008 and Visual SVN. Should I create 2 completely different solutions, create one solution with duplicate projects, or create branches? Branches seem like the elegant route, but what is the idea? Create a "Lite Version" and "Enterprise Version" from the trunk... with the trunk being the "Lite Version"?
It depends on how much your code differs between the two. In the best case, if it's simply a matter of linking to different assembly versions, use NAnt or similar and simply create a build target for each one.
If life isn't quite that utopian, I'd create three projects on one branch: one class library to contain all common code, and another class library per version that only contains unshared code.
If the shared code has dependencies on those multi-version assemblies, though, you're more or less stuck doing things manually, as far as I can tell. That means maintaining a branch-per-target and doing regular merges between them to keep shared pieces in sync. Using a distributed CMS would ease the pain of merging, and creating a battery of unit tests will help reduce the amount of error these cross-project merges introduce.