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.
Related
I am working on a C# program that utilizes EntityFramework, I've cloned the program from git repo, but now it is having that dreadful Metadata file 'EntityFramework.dll' could not be found error. I have searched and tried countless suggestions for this kind of problem, but none worked. I've already checked that the reference to EntityFramework.dll in the .csproj files are correct and it is definitely there under the packages\EntityFramework.6.2.0\lib\net45\ folder. So I am not sure what else to try.
Ok, I've resolved this problem. Here is what happened. Apparently, when cloning into local directory, one of the folder on the path has a space in its name (like My DSS), and this nuget issue seems to indicate the inability of nuget to find package with space in path. So, once I changed that folder's name to MyDSS, it compiled successfully.
please have a look on the bin folder ,sometimes the dlls do not exist there .
This typically happens when teams check in files that should not be checked in (such as the .suo file) or have "optimized" their builds to exclude rarely changed projects. (unticking projects in the configuration manager.)
Another common cause for missing references is when devs reference a dependency from a /bin folder instead of the packages folder, but it sounds like you've confirmed that isn't the case.
Other questions such as Metadata file '.dll' could not be found list a number of things to check, so your problem will surely be one of these. Try building each project individually, working from projects that have no project dependencies upwards to the main application project(s). Ensure they're running the same .Net versions, check the solution NuGet packages for dependencies with "multiple versions" and consolidate these so that the solution is using a single version of each dependency. (generally good for cleaning up) Also look at .config files for version re-directs that sometimes get zombified in source control.
In Visual Studio, on top, click on Build -> Configuration Manager. Make sure that the build checkbox next to your project is checked. In case it already is, uncheck it and then make it checked again. Clean your Solution and Build it again after this.
If there is a code library in a single file, is it possible for Visual Studio to "include" it remotely?
Consider a library I wrote -- Nemmet. Basically, the entire thing exists in a single file, by design. It's a very limited library, with barely any dependencies.
For people to include the source (even myself, in other projects), they would have to do one of the following:
Download the repo and add the project to their solution
Create the file, and copy and paste Nemmet.cs into it
Yes, they could install a Nuget package, but then you get the compiled DLL in your project, not the source. Nuget is really about functionality, not source code. Additionally, it requires me as the library owner to create and maintain the package, which I'm really not that interested in doing.
What I'm looking for is a more "casual" way of including raw source code into a project.
What would be nice is if Visual Studio could do a "remote include" or something. I'd love to be able to bind a source file to a URL (the "raw" URL at Github) and have VS update the contents of the file every once in a while, or on-demand (right click > "Update from URL").
(Yes, this assumes you trust the source. Let's assume you do. You'd have the same issue with any included library.)
Is there anything like this available in some way? Should I just WGet it? Am I not thinking of a more obvious way to achieve the same end?
You can use Paket which is a dependency manager for .NET projects. Many of us in the F# community use it quite a lot but there is no reason it isn't equally applicable to the rest of the .NET world.
Basically, you create a paket.dependencies file for your project to list your dependenies. It supports:
Nuget dependencies:
nuget EntityFramework
git repositories
git https://github.com/fsprojects/Paket.git
Single files
http http://www.fssnip.net/raw/1M/test1.fs
Github dependencies
github forki/FsUnit FsUnit.fs
Here is the getting started guide.
This is not quite the same thing, but I found a way to "Add as Link" in a Visual Studio project. You can add a source code file without actually adding it to your project.
When adding an "existing item," dropped the "Add" button down to "Add as Link." It will add a placeholder to the file to your project, and compile it in, but leave the file where it is. This means you could have a central project on your file system, and use that code in all sorts of projects without having multiple copies of the file sitting around. Changing the file in your central project would change it in all the other projects.
Again, not the same thing, but still helpful.
I have a smallish solution, with about under twenty projects. The solution used to also contain about six source projects written by a third party service provider, ACME. Now, finally, this other party is supplying us only with a handful of DLLs. I used to just included their source, one project per DLL, in the solution, and so I am looking for a neat way to include all these assemblies in the solution, so they can be referenced from the many projects that need them.
My immediately apparent options are:
Create an AcmeAssembly project, add all DLLs as project items set to copy to output.
Create an AcmeAssembly solution folder. Quicker and simpler than a 'binary-only' source project, but solution folders have the very, very large drawback of having no means of grouping the files without a solution file, i.e. outside of VS.
Create a NuGet package that includes all the required binaries. Then at least we also have a partly 'phycical' grouping in the packages folders. My problem here is I have never written a NuGet package, but I am not asking how to here. I am asking about three candidate solutions, and more will be welcome, and if NuGet wins, I get to learn to write a package.
I can't simply use the project's output bin\debug and bin\release folders. To me, these are strictly output folders, and nothing but other dependency assemblies should also be output there. Deleting the bin folder should have absolutely zero effect on a build, so that is certainly no place to store binaries.
The advantages of nuget over the other solutions are:
Support for versioning
Support is built in into Visual Studio and MSBuild
No 'magic folders' that all developers need to have on their machines
Create your Acme library folder (something like: C:\Source\Library\AcmeLibrary). Put all of your Acme dll's in that folder. Then create the Solution Folder in VS and add the existing items to it (don't add the folder, but the items in the C:\Source\Library\AcmeLibrary folder to the solution folder using "Add Existing Item..." menu selection).
I have some c# projects. I added post build event to those projects that copy the resulted assembly (dll) from the bin into common folder.
It appears that each compile generates assembly which is binary different from the previous even when I don't modify the project files.
It is quite a problem for me since I'm using Kiln that monitor those file and think they were modified.
I read somewhere that the dll stores time stamp of compilation which if true then I cannot fix this. If so how do you manage your shared DLL in such a way that your repository (Git/HG) doesn't commit all your compiled projects that weren't modified?
Thanks,
Eran.
To address the specific question of "How do you manage your shared DLL in such a way that your repository (Git/HG) doesn't commit all your compiled projects that weren't modified?", I have a very simple answer: ignore.
We exclude /bin and /obj from the directories which our source control will even attempt to commit. This does mean that you will need to recompile the code on each machine after each change, but Visual Studio would do that anyway for any project where the code has changed.
Don't commit the output folders of your projects.
If you want to have a Setup folder or something similar that always contains the latest versions of the assemblies created by your projects, the solution is to make sure that your post-build event is configured to run only when the build updates the project output. There is an option that is named like this:
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).