xsharp.eu

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:xsharpSolution1 and d:xsharpSolution2). These solution both use a shared C# project, stored in say d:csharpCSharpSolution).

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

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

https://www.codeproject.com/Articles/12 ... ep-by-Step

Private nuget package
https://docs.microsoft.com/en-us/nuget/ ... s/overview

/Mathias

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

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

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

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

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.

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

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:xsharpSolution1 and d:xsharpSolution2). These solutions both use a shared C# project, stored in say d:csharpCSharpSolution).
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

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