I got a c# solution developed by other developers.
This solution contains 30 projects and there is also git folder.
Every project has its bin/ folder. I have web site and class libraries. All the code has poor quality: eg bin e obj folder are included in git.
I'm refactoring the code and reconfiguring also git. I don't want to include bin/ folder in git, so I have created a dll folder in the root of every project containing libraries in the bin/ folder. In this way also references in visual studio have not any warning.
Is it right? Are there other methods?
Second question: if I have a dll in the bin folder not present in the references, would I link that too? Or can I not consider it?
EDIT:
EG: in a class library (not in umbraco project):
- bin/umbraco.dll
- bin/umbraco.provider.dll
- bin/umbraco.core.dll
- bin/lucene.net.dll
In visual studio is referenced only:
- umbraco.dll
So three ways:
Include bin folder in git and if i need to edit this project i will
understand ho configure it;
Add a dll folder in the root (and in git), copy umbraco.dll in it. So references in
visual studio are ok. But only umbraco.dll will be copied in bin
folder. And the Others? Will i need them?
Add a dll folder in the root (and in git), copy all dll files in it.
So references in visual studio are ok. And i take Others for future
uses.
I choosed 3rd solution.
I don't want to include bin folder in git
Simply make sure you have a .gitignore which declares what you don't want:
bin/
That way, you don't even have to create a dll folder. Or if you do, you can ignore bin/dll/ in that same .gitignore file (note the trailing '/' for ignoring folders in a .gitignore).
For CSharp projects, gitignore.io proposes this .gitignore file.
If I ignore bin folder and you pull, the project will not compile!
git should always ignore (big) binaries: those dependencies, as commented by Iain, should comes from an artifact repository (like Nugget) or other externa referential: external to the git source repository, which is made to track the history of sources (text files), not to store binary dependencies.
But if you must, copy only the dll referenced by your project (umbraco.dll) in a versioned folder, and see if the project compile/works. Then add the missing one.
If you have to version those binary dependencies, it is best to try and version only the minimum amount of dlls.
Related
I have created a library, with its own git repo. I want to include it in a Unity3D project, but I also want to be able to adjust the library from within the working solution.
Context
Unity
Unity automatically (re-)creates its .sln and .csproj files, so
I can't set the library .csproj as a reference there. In order to use a DLL with Unity, it has to be put in a special "Plugins" folder and will then be included in the auto-generated files.
it's impractical to use Unity's auto-generated .sln for... well, anything other than the Unity project itself.
Library
The library has its own git repo, included as a git submodule. I understand that I can change the output path of mylib.csproj to point to that Unity "Plugins" folder, but then that would be saved in the library git repo - which would make the whole repo moot by having it only work for this project.
Current State
I put the library and Unity project inside a "master solution" and currently have the following structure for that:
-mylib (solution folder, but also a file system folder containing the git submodule)
-mylib.csproj
-unittests.csproj (for mylib)
-Unity (solution folder, but also a file system folder containing the Unity project)
-Assembly-CSharp.csproj
-etc., all the auto-(re-)generated files
-unittests.csproj (for the Unity project)
Goal
What I want to achieve is being able to build mylib.csproj and have its DLL automatically be put into that "Plugins" folder in the Unity project. Given the restrictions mentioned in the "Context" part, is this possible?
I am currently using Visual Studio Community 2017 to set this up, but it has to be possible to work on the end product with other IDEs, especially JetBrains Rider.
Avoid library and Unity .csproj
I now found a solution, much less involved than I thought it would be.
I added a new, empty project to the master solution - I ended up literally calling it BuildToUpdateLibraries - and then did the following things:
set the output type to "Class library"
This way, the project doesn't need a main method, so we can build without actually having any code at all - a build will just create an empty BuildToUpdateLibraries.dll.
added the mylib project as a reference
This will copy the mylib.dll to the BuildToUpdateLibraries output folder.*
Now we can freely edit the BuildToUpdateLibraries.csproj file and will neither make the libraries unusable elsewhere nor have Unity overwrite it on every rebuild.
Copying to the plugins folder
Now, the one last issue here is that when building, we get more than we want.
There is the useless BuildToUpdateLibraries.dll, but also every .dll mylib depends on*. You might actually need (some of) these, but in my case it was the UnityEngine.dll. That .dll is part of Unity and importing it again probably only leads to problems.
Thus, setting the output folder of BuildToUpdateLibraries to the Unity Plugins folder is not an optimal solution. However, as we can now freely edit the BuildToUpdateLibraries .csproj, we can just add post-build events. I added the following line in the post-build events to copy the file:
xcopy "$(TargetDir)mylib.dll" "$(SolutionDir)Unity\Assets\Plugins\MyLib"
Now when I build BuildToUpdateLibraries, it will first build mylib and then build BuildToUpdateLibraries with the mylib.dll included. Finally, it will copy the file to the Unity plugins folder.
*There is an option to not include a .dll in the output folder, but default behaviour is to copy and you would have to do that for every file.
The DLL files under _bin_deployableAssemblies belongs to SQL Compact....
apparently do not get installed via Nuget (neither with Microsoft.SqlServer.Compact 4.0.8854 or EntityFramework.SqlServerCompact 6.1.1). Exclude the _bin_deployableAssemblies from Git and when a co-worker cloned the project only "shadow" copies of the dll files were present. The automatic build copy process from _bin_deployableAssemblies to bin failed for him.
Don't have a history of my Nuget installations but I suspect either a package setup up this dll or I did it somehow in the solution.
Read Michael Dudley's blog about pushing SQL Compact with projects. Along with a Nuget setup that tries to address 4.0.0.1 assemblies.
Is there a reason why these dll are missing when cloning the project? Why the shadow copies then?
Is there a reason why these dll are missing when cloning the project?
Perhaps because executable files and bin directories aren't usually considered source files under version control.
Why the shadow copies then?
The "shadow" copies are presumably the items in the project file, i.e. the DLLs are identified in the project file
Me and my team just started using GitHub for our development.
Our project is written within Visual Studio (C#).
In our project files we have external references of .dll files that are saved in specific folder for each user for example (c:\users\$user\dlls\data.dll).
When one user is commiting it's changes - it's also including the .csproj files who contain the links for those .dlls but when another using is pulling from the tree the .csproj contains links from the other user's .dll file and he have to change manually the references in order for it to work.
We tried solving it by putting the .csproj files into .gtignore - though that back fired once our project development expended and each branch has different files.
During the writing of this post I thought of another solution - removing the .csproj from the .gtignore and moving all the external .dlls into folder with an agreed file path such as (c:\dlls) and that might solve our problem.
My question is this:
Is there another solution for our issue?
I haven't tested my suggested my solution I will give it a try next version - What do you think of it? Is that the way to go?
Thanks ahead for your replies,
H.
Why aren't you "sharing" those external DLLs in a folder in your project? What I do is add a folder named "External" in my solution which contains these DLLs (and PDBs and XMLs etc) and make sure it is also checked in. That way whenever someone adds a DLL, all other developers simply need to get the latest files from Git and it is on their machines.
Of course, only do this for DLLs that aren't available from NuGet.
It looks like you need a dependency manager such as NuGet or an alternative one.
I have 3 projects in my solution and a bunch of 3rd party or company dlls. Each time I rebuild my project or clean solution, a lot of this dll's are deleted, therefore missing. It is pretty annoying to reference this dll files again and again after rebuilding. Can someone explain how to avoid this? Thanks in advance.
The bin folder is just the binary output from a build, so when you clean your solution, all the assemblies in the bin folder get deleted. You should reference the assemblies from some other location. One suggestion is to create a Shared Resources folder within your project, copy your assemblies to that folder, then reference them from that folder. This way they won't get deleted from bin on a clean/rebuild and Visual Studio will copy them there as needed.
Right-click on the References folder in your project and choose Add Reference...
Use the browse functionality to locate the assemblies you want to reference (don't worry about manually copying them to/from your bin folder)
After the reference is added, right-click on the reference in your references list and choose Properties
Make sure the Copy Local property is set to True
This will ensure that assembly is copied to your bin folder on every build.
In my case, .net framework version is the problem. I had to lower its version to 4.5 and then the projects got built properly and able to reference in other projects
As Troy explained in his answer, indeed a reference to a *.dll file, kept outside the bin folder, ensures that the dll file does not get definitively wiped out when cleanning the project.
However, just by adding a reference to the assembly might not be enough. For instance it would not work for some other file types, such as the *.pdb files as well as for the *.resources.dll files (which are typically spread in many sub-folders named after the language codes (2 letters' language code)
To depict this problem with a real life situation, I picked up an assembly for which the source code is either gone, or not compatible anymore, etc. I chose (on purpose...) a 13 years old AjaxControlToolkit composed of many component files. The picture below illustrate its composition. Every time the "Clean" command is applied to the project all these files are deleted, except the one which is the referenced assembly. Moreover having several *.resources.dll file assemblies of the same name, as in the present case, makes it inconvenient, if not possible, to add "references" to each of them from within the same project.
Nevertheless here is a pretty simple workaround:
keep this file hierarchy in a separate folder (as Troy explained in his answer)
just copy them over in the bin folder using a command line entered in the Pre-build event of the project, such as xcopy "$(SolutionDir)AjaxControlToolkit" "$(TargetDir)" /y /i /s /r /q
Hoping that will be useful to someone...
during development of our application we use a branching structure and while we are developing another team is using earlier builds of our software to create content with it.
To facilitate easy swapping between builds and teams I was hoping to use empty Hintpaths in the content projects' csproj files so that they can use our GAC installed assemblies to build against and in the meantime add a reference path to the projects for our use during development and test cycles where we don't want any assemblies installed in the GAC.
However, it seems reference paths are not stored in the csproj file and thus don't get sourcecontrolled. Since there will be extensive branching it would be less than ideal to have to set all reference paths again when a developer pulls another branch from sourcecontrol.
I've been searching for a bit now and can't seem to find ways to do this. Anybody know of a way to force the reference path in and out of sourcecontrol?
We're talking Visual Studio 2008 and TFS 2008 here.
Cheers,
Anton.
Ok, I seem to be a little clearer in the head after a good night's sleep, took the logical step, namely investigate where exactly the information was stored and how. It turned out the information was stored in the .user file for the project in the project's folder and as it turens out this file contains mbsuild xml.
I then did what I wanted as follows:
Create the Reference path as I required it to facilitate both scenarios without any work.
Browse to the Project's .user file
Copy the PropertyGroup containing the ReferencePath
Paste the PropertyGroup in all the necessary Projects' .csproj xml.
Reload and build.
Done.
The references are stored in the *.csproj file. The nodes are ItemGroup/Reference...
Thomas
This is pretty simple--we do this in our shop.
First, in the Workspace (using Windows Explorer, browse to the Solution folder), create a folder. We name it "Referenced Assemblies". In here, drop all your DLLs.
Now, in the Solution, add a new folder to match the one created in Windows Explorer. Into that folder, add all the DLLs you just dropped in.
Finally, in each project, set up your references to use the DLLs that were added to the solution.
Now your project references DLLs that are part of the solution, so that when the build runs, it will grab the DLL from Source Control to generate the build.
Also, I'd recommend not using the GAC at all if you can avoid it. In my experience, reference behavior is strange. It seems references go first to the GAC, then to the DLL in the local folder, meaning that if the DLL is updated, the one in the GAC is used instead of the DLL in the local folder (which is likely the updated one).