fbpx
Welcome, Guest
Username: Password: Remember me
  • Page:
  • 1

TOPIC: More source control questions: shared projects

More source control questions: shared projects 7 months 2 weeks ago #1

I am still having trouble understanding how I can define a repository. I am currently trying that with Git; only not on Github but I think the issue is the same).

Consider this (simplified it a little bit). I have 2 solutions. Both contain an X# project (say in d:\xsharp\Solution1 and d:\xsharp\Solution2). These solution both use a shared C# project, stored in say d:\csharp\CSharpSolution).

Now when I would select File/Add to Source Control in VS, I get the following message:

Source Control - Git The current solution has projects that are located outside the solution folder. These projects will not be source controlled in the Git repository. To add all the projects to a single Git repository please consolidate all projects under a single folder.

This sounds insane to me. It would mean that I would need to make local copies of the C# library in each solution using it! Suppose I have 6 of such solutions and I change the C# code in one of them, I have to manually make changes in the 5 other copies.

Apart from that I would want to have the repository files outside my project so when the project disk crashes I can restart with a backup and pull the changes from the local repository.

The synchronizing via the cloud system also with other users (in my case Bitbucket) seems to be the least problem.

How are others doing this?

Dick

Please Log in or Create an account to join the conversation.

More source control questions: shared projects 7 months 2 weeks ago #2

We have published it as a nuget package. When a new version is published, the new version is downloded to our projects when building.

www.codeproject.com/Articles/1214420/Cre...Package-Step-by-Step

Private nuget package
docs.microsoft.com/en-us/nuget/hosting-packages/overview

/Mathias

Please Log in or Create an account to join the conversation.

Last edit: by MathiasHakansson.

More source control questions: shared projects 7 months 2 weeks ago #3

MathiasHakansson wrote: We have published it as a nuget package.


Hello Mathias,

I'm afraid I fail to understand what creating a Nuget package has to do with the problem I described but apart from that I've read your activities with interest. I actually never realized that you are Melbourne based.

Are you or have you been in touch with Geoff or Paul?

Dick

Please Log in or Create an account to join the conversation.

More source control questions: shared projects 7 months 2 weeks ago #4

Hi Dick,

I'm in Sweden, though I'd love to go to Australia some day...

As we have not migrated to Git yet I am not familiar with it.
The question was about how to have a project shared between different solutions. In our case we avoid that problem by distributing a common package with nuget. The nuget package can be used in more than one solution.

/Mathias

Please Log in or Create an account to join the conversation.

More source control questions: shared projects 7 months 2 weeks ago #5

Hello Mathias,

I'm in Sweden, though I'd love to go to Australia some day...


I thought something like that. But when I clicked the link I thought the CodeProject page was your solution and didn't further check the name of the (Australian) guy who created it ;).

As I do use Git now I would like to solve it first within the Git repository, Visual Studio, in SourceTree or whatever solves the problem.

It surprises me that nobody has -yet- shared a solution for this. I'd say that shared projects between multiple solutions should be very common but yet VS directly tells me I have to move the shared project to the solution directory. Probably I have to do this this: create a new solution containing only this "external" project with a separate repository on Git. But I am not sure if that allows me to commit changes from the other solutions when I edit something in that project from there. Or if this means I have to open the souce code controlled solution if I want to change something in it, which would be very clumsy I'd say.


Or is every .git user seriously copying the same code to multiple solutions in order to get it in 1 Git repo?

Dick

Please Log in or Create an account to join the conversation.

Last edit: by ic2.

More source control questions: shared projects 7 months 2 weeks ago #6

Hi Dick,

suppose you could share a project outside of the solution directory. How would that work when dividing your work in different branches? What would happen to the project outside of the solution folder?

The nuget packages are maintained in the solution and you can manually decide when to update them. This means that you don't have to update the nuget package in all projects at the same time and parallel branches are truly separate (until you you do reverse or forward integration).

/Mathias

ic2 wrote: Hello Mathias,

I'm in Sweden, though I'd love to go to Australia some day...


I thought something like that. But when I clicked the link I thought the CodeProject page was your solution and didn't further check the name of the (Australian) guy who created it ;).

As I do use Git now I would like to solve it first within the Git repository, Visual Studio, in SourceTree or whatever solves the problem.

It surprises me that nobody has -yet- shared a solution for this. I'd say that shared projects between multiple solutions should be very common but yet VS directly tells me I have to move the shared project to the solution directory. Probably I have to do this this: create a new solution containing only this "external" project with a separate repository on Git. But I am not sure if that allows me to commit changes from the other solutions when I edit something in that project from there. Or if this means I have to open the souce code controlled solution if I want to change something in it, which would be very clumsy I'd say.


Or is every .git user seriously copying the same code to multiple solutions in order to get it in 1 Git repo?

Dick

Please Log in or Create an account to join the conversation.

More source control questions: shared projects 7 months 2 weeks ago #7

We do the same thing here: shared libraries are placed in a separate solution and published via NuGet (on an internal server of course, not the whole world needs those libraries).

We have like 4 solutions that reference the same nuget package.

Please Log in or Create an account to join the conversation.

More source control questions: shared projects 7 months 1 week ago #8

Hello Otto, Mathias,

Thanks for your reply but to be honest I don't understand a word of the nuget article in combination with, as I thought, the simple requirement to have code in a solution residing outside the solution included in source control. As Mathias wrote not using Git I am not sure if what you write is the solution for my issue.

Basically the only thing I tried so far is to have a solution on the Pc's of multiple programmers so that one programmer can update his project with the changes of the other. And preferably without copying commonly used code in every solution.

Even the basic source control commits don't t work. Last result is

Git failed with a fatal error.
HttpRequestException encountered.
An error occurred while sending the request.
cannot spawn /C/Program Files (x86)/Microsoft Visual Studio/2017/Community/Common7/IDE/CommonExtensions/Microsoft/TeamFoundation/Team Explorer/Git/mingw32/libexec/git-core/git-askpass.exe: No such file or directory

Seems some problem with the Git Credential Manager or Visual Studio 2017, but bottom line is that literally anytime I start doing something with or related to Visual Studio I have to spend more time solving problems than that I have time to code.

If I finally solve this, one never knows, I'll add an article about it for the X# Documentation Project.

Dick

Please Log in or Create an account to join the conversation.

More source control questions: shared projects 7 months 1 week ago #9

Hi Dick
A pint says you won’t find a way of doing what you are trying to do.

Repositories as in VO have no part to play in the .Net World. No doubt you could “think” some round-about route to link the ideas behind it all – but I doubt that would be much use.

You have 2 solutions. Both contain an X# project (say in d:\xsharp\Solution1 and d:\xsharp\Solution2). These solutions both use a shared C# project, stored in say d:\csharp\CSharpSolution).
Instead of thinking “projects” think “assemblies”.

What you need is a single solution (Application) containing whatever assemblies you need. Each assembly can be in whatever .Net language you like as long as you don’t try mixing languages in the same assembly.
That way the solution is effectively what I think you are trying to consolidate anyway.
Thus, you now have a single solution which references any number of assemblies.
In VS, for example, you would have a “Start Up” project1/assembly1 referencing two separate projects/assembly2 and project/assembly3. (or more if you like).
The only thing you need to remember is that the code in each does not give rise to circular references – but VS is likely to flag this up anyway.
The .Net world is a vast electronic eco-system, within which Microsoft has given us the tools to do anything that the electronics of digital computer can do. The most significant thing is that XSharp or indeed CSharp is based on the Roslyn Compiler.
Roslyn enables us to actually program the compilation process, something hitherto not possible. The potential benefits of this, as you may guess, are enormous.

Terry

Please Log in or Create an account to join the conversation.

More source control questions: shared projects 7 months 1 week ago #10

Sorry Terry,
What has this to do with Dick's problem? AFAIU, he wants to sync code more than one coder writes plus automatic availability of some be code...
Karl

Please Log in or Create an account to join the conversation.

More source control questions: shared projects 7 months 1 week ago #11

Karl,
What I read is that Dick has 2 folder structures:
C:\CSharp
C:\XSharp

and wants to manage these under Git at the same time
I think that this is not possible.
To manage code at the same time there has to be a common folder.
You can do this in 2 separate Git repositories, but I do not really understand what the use is to group projects by development language.
Most customers that I have worked with/for use a different folder structure.
Something like:

C:\Projects\Project1
C:\Projects\Project1\Library1
C:\Projects\Project1\MainExe
C:\Projects\Project2
C:\Projects\Project2\Library2
C:\Projects\Project2\Library3
C:\Projects\Project2\MainExe
C:\Projects\SharedCode
C:\Projects\SharedCode\SharedLibrary1
C:\Projects\SharedCode\SharedLibrary2

In this layout I would create a Git Repo at the levels Project1, Project2 and SharedCode
Even in this layout it will be difficult to checkin Shared Code and Project specific code, but at least you are then following the common logic that the whole world uses.

Robert
XSharp Development Team
The Netherlands
This email address is being protected from spambots. You need JavaScript enabled to view it.

Please Log in or Create an account to join the conversation.

Last edit: by robert.

More source control questions: shared projects 7 months 1 week ago #12

Hi Karl
You’re right – probably nothing, just an aside.
I was trying to give a possible reason for the error messages Dick was getting when trying to do what I understood him to be doing.
Terry

Please Log in or Create an account to join the conversation.

More source control questions: shared projects 7 months 6 days ago #13

It all boils down to the question;

In which Git-Project does the shared code reside?

If the shared code resides in several different Git-Projects at the same time you would not be able to version control your code. Which Git-Project holds the latest code change? Merging simultanious changes will not be possible.
If you branch your code you will get a new solution folder on your disk. This folder will contain the full solution. What happens to your shared code then?
Read more on branching strategies on www.javacodegeeks.com/2015/11/git-branching-strategies.html

One way to (sort of) do what Dick wants is to have all applications in the same solution. This way of doing things has several disadvantages. The applications may not have the same life span, release dates or developers. Compiling will take a long time. It's much better to divide your solution into smaller parts and treat your shared code like a third party component. Update in each project when convenient, either manually or with nuget.

/Mathias

Please Log in or Create an account to join the conversation.

More source control questions: shared projects 7 months 6 days ago #14

Thanks, all for the comments. @Terry, it looks like the error is a problem in the Git Credential Manager which reoccurs every time again. See this link "Can't login to GitHub" github.com/github/VisualStudio/issues/949 which started 16 month ago and has new comments up 'til today. Someone suggested the hashtag #MicrosoftShouldNotMakeSuchStupidMistakesInTheFirstPlaceBecauseWhatIsTestingForAndTls1.2ExistsSinceALongLongTime and I can only agree with that. It's really frustrating that the life span of once working setups with everything with and around Visual Studio is sometimes not more than a few days after which one can spend hours to get it working again .

And it's X#/C# only I use it for. For VO we exchange .prg's/mef's/.aef's and sometimes the whole repository. And VOPP provides daily backups to compare too if necessary. Not ideal, certainly not, but it works without the problems I encounter with whatever Source Safe I tried on VS.

Robert's answer is closest to what I want. Dividing C# and X# projects in directories is not really necessary but from your reply I also understand that even putting it in 1 directory won't work as I would expect. In short, if I am working on a solution which includes a C# commonly used project, found on C:\Projects\SharedCode\SharedLibrary1, and I make a few changes from the solution in C:\Projects\Project1, it means that the source control of C:\Projects\SharedCode\SharedLibrary1 is unaware of these changes. So I have to open a solution under source control containing C:\Projects\SharedCode\SharedLibrary1 as main project otherwise I can't exchange changed code.

I don't need different branches and whatever elaborate options source control may have. I just want to make sure that everyone in my team can update their version of the project with the changes the main programmer made. And maybe the other way around. Without having to think how & from where I open the code to maintain.

If that's impossible, and it looks like it is, source control could as well be replaced with a simple file comparison program which collects the real changes and sends them to other users. It would meet my simple requirements, without all the potential elaborate options but also without the problems I've been seeing since I started implementing this.

Dick

Please Log in or Create an account to join the conversation.

More source control questions: shared projects 7 months 6 days ago #15

you can do the following:
1. designate one head parent folder. One to rule them all
e.g. c:\projects
2. inside that folder you put your projects, the shared and the non shared projects.
3. in that main folder, create the solutions with the projects you want to combine.
e.g.
MySolution 1: containing Project 1, Project 2, and the shared project(s)
MySolution 2: containing Project 2 and the shared project(s)
MySolution 3: containing Project 4 and the shared project(s)

And if you like, One solution to rule them all containing Project 1, Project 2, Project 4 and the shared project(s).

We do this all the time.

But, consequences of using shared projects this way, is that you have to make sure that the shared project works together with all your projects before you can check in.

If however you create a nuget package for the shared projects, you can safely and controlled upgrade the assemblies of the shared projects for Project 1, 2, 3 and 4 independent of each other.

Please Log in or Create an account to join the conversation.

More source control questions: shared projects 7 months 6 days ago #16

Hi Dick

Yes - that's right.

Terry

Please Log in or Create an account to join the conversation.

More source control questions: shared projects 7 months 6 days ago #17

Quick reply. For now I solved the above error by copying the binaries from the "<VS_INSTALL>\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\Git\mingw32\bin\" folder to the "<VS_INSTALL>\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\Git\mingw32\libexec\git-core\" folder. Not sure if it's a problem in combination with Bitbucket (as I do see the problem mentioned in very recent posts concerning Github). Seems to be absent with VS 2017 before 15.7.5 (updating to 15.7.6 did not solve it). Anyhow, good reason to not update VS for the rest of the year - if this keeps working.

I'll check out all the advices next.

Dick

Please Log in or Create an account to join the conversation.

  • Page:
  • 1