We are using TFS and VS 2010.
I have been working on a project that is using TFS as source control.
I have quite a few dlls that I have downloaded (such as log4net) and referenced in my project.
When a new programmer connected to TFS and got my project out of source control, it failed to build as it said it was missing all these referenced dlls.
What did I do wrong here? How can I include those referenced DLLs in source control.
Do I need to add all these dlls to my project before referencing them? when I referenced them, I just browsed to where they were on my file system.
I've found the best practice for 3rd party DLLs is to create a "Library" folder in your sln/proj file structure and copy all the necessary DLLs into this local folder for reference. You'll also want to make sure these DLLs are checked into source control. This way, everyone who works on the project gets the exact same versions of all DLLs, and the reference paths are exactly the same.
Referencing 3rd party libs in a arbitrary download or install location will be problematic, because it will require all developers to maintain the same download structure for all DLLs. Also, if everyone references DLLs outside of the project structure, it's harder to guarantee that everyone's on the same version.
The other option would be to have everyone install the DLLs into the GAC, but that can be a real pain too, especially with version management and deployment.
I created a "ThirdPartyDLL" folder in my project folder in which I copied all the extra DLLs into it. I then went into source explorer and added those DLLs into the team foundation server so I could be sure I'm using the correct versions of the DLLS for specific versions of my application (and so everyone else is on the exact same page as I am).
View - other windows - Source coontrol explorer
Right click project folder - add items to folder
You won't be able to select a specific folder with DLLs in it, but instead you can select the individual DLL files within the folder. You will then see the "ThirdPartyDLL" folder appear in that window.
Once this is done, those dlls are in the team foundation source control. Whenever a dev checks in, they will get the most current version of the DLLs.
Don't forget to remove the old references in your app and change them to your thirdpartydll folder.
I used to copy the DLLs into the bin folder but the issue I ran into was when the DLLs got upgraded. Initially when my project was small it wasn't a big deal. Now that I have multiple DLLs and applications that I created it became very difficult to maintain consistent versions of DLLs outside my project. My best example is the licensing dll I purchased. When this got upgraded all applications and libraries needed to be on the same version. If I forgot one then I had weird issues or the application just stopped working. Now that I have everything in one folder, I make the change once and everything is upgraded.
Hope this helps.
Andy's suggestion is a good one and I've used that in the past. At my current job, we have a "reference" folder on a network share for all of us to build from. We have a very fast network here, though and all developers are in a single office. This solution won't work as well if you have a lot of remote developers or a slow network.
I've tried various methods for dealing with this and have settled on dropping required dll's in the bin folder and making sure they are included in the project for source control. I've heard people say this might not be a good idea but nobody has provided good reasoning for it and it's worked well for me.
My second choice would be to carve out some space on a network share and organize the various 3rd party dll's there. You can put your files in folders with verion numbers to keep things straight and everyone should have access to everything they need, so long as everyone uses the normal network paths as a reference.
Adding a seperate folder within the project is also workable but seems messy, since you end up with extra files that you don't want included in your release.
Related
I have a visual studio 2019 solution with a few projects that consist of mostly c# class libraries. This solution is never 'deployed' and is always run locally by anyone who uses it. Part of what we do for one of our test projects to work is put certain dll's we use into our bin/Debug folder. One of these is Newtonsoft.Json.dll for example. We have a specific version of that dll that we're required to use.
This is something that is usually done once, the first time we run a test in that project. This all works fine. However, whenever there is a code change and the project builds, for whatever reason all the files that are in "C:\Program Files\IIS\Microsoft Web Deploy V3" are copied into our projects bin/Debug directory and overwriting any of the same files already there (Newtonsoft.Json.dll being one of them), and it's a different version which then breaks our projects dependency on that version of the dll. It's worth nothing there are also a bunch of random other files/folders in that Web Deploy directory that get copied over that our project does not need to be there.
I've checked all build events, and searched the entire solution to see if we reference that directory at all which we don't. I've tried googling similar issues, but almost all of what I can find is related to how to use Microsoft Web Deploy (which as far as I can tell we're not, and intentionally as I mentioned we don't deploy any of this code).
If anyone has any insight on this, it would be greatly appreciated!
Thanks,
Andy
I'm new to c#, and i'm stunned by the amount of files that are generated by my release output.
I wrote a REALLY simple program that i want to distribute, no external assets or anything special.
but still, there are 10-15 files generated (.dlls, .pdbs, .configs, etc. etc.)
I did a little research yesterday and i got the impression that it is simply not possible to clean up this mess without a REALLY big hassle?
i tried Fody (didn't work at all) and Tidybin (or something like that?) (created a lib folder and put everything there, which was nice, but the program stopped working and threw errors about the missing files)
I'm looking for a way to generate a clean release version.
ideally with JUST my exe, with all the dlls and other stuff embedded, but everything i read about that was just way above my head and overly complicated (why isn't this super easy to do???)
if that's not possible, i'd be happy with moving everything except the .exe in a lib folder. but that didn't seem to work. how do i update the path inside my application, so that those files can still be found? like i said, that plugin seemed to do half the job, while leaving all links like they were.
(side note: why is there not ANY KIND of ducomentation for all of these plugins? i really don't have the SLIGHTEST idea what to do)
thanks
If you have a simple application, there shouldn't really be that much in the folder.
Actually, there should be:
1 exe, 1 pdb (only for debug build), 1 exe.config file for the application
1 exe, 1 pdb (only for debug build), 1 exe.config file for the Visual Studio Host Process
If there is the System.Net.Http library referenced, this could create a folder with many localizations. If you don't use it: Remove the reference.
Please note that you do not need to deploy all these files! If the application only references framework DLLs, all you need is the .exe and .exe.config file.
DLLs will not be embedded, but if they are framework libraries, they should not be added to the output folder unless you set the "Copy Local" property of the reference. And you don't need to deploy them along with your application, as obviously they are installed along with the .NET framework on the target system anyway.
If you reference any DLLs that do not belong to the .NET Framework, you normally deploy them along with your application. It's easiest to put them in the folder along with your application, but you can also put them in the global assembly cache on the target system.
There are solutions that package the executable, third party DLLs and stuff into an EXE wrapper that is unpacked every time you start the application, but I advise against this. The user won't expect this to happen, virus scanners may block this and builtin mechanisms like .NET settings may not work properly for those solutions.
The easiest way to distribute your code is using InstallShield Visual Studio edition. (That is available with your Visual Studio license)
Download and register, then add a new distribution project to your solution.
InstallShield Limited Edition for Visual Studio
A wizard will help you by selecting the main distribution files. And it is a useful tool distributing new releases of your application.
As a second option I use is ClickOnce (Microsoft), but for specific internal applications.
ClickOnce Deployement
I have a big solution with 30 projects of which 2 are web projects (MVC and WebAPI) with a bunch of background class library projects.
I have visual studio set up to host the web projects in IIS.
If I do a clean build, followed by a full build of the entire solution, then accessing both projects via a browser works fine. (they are in diff folders and hosted on diff 'domains' in iis)
If I make NO code changes, simply rebuild one of the 2 web projects, the OTHER one stops working.
To be clear, rebuilding the WebAPI project causes the MVC project to have errors. And vice versa.
The error I get is saying that System.Web.Http.Formatter is not found. The detail says that the located assembly version is different from the reference version. Checking the bin folder shows that that is not the case.
Make sure that all the solution's resources are up to date. If you use Nuget, update all packages in all projects (back up first!). It sounds like you have a version mismatch, where functionality is missing in DLLs copied to the output directory for the solution. It may involve changing some entries in the Web.config of each project, but without access to the code, it's hard to know for sure.
Report back once you've updated every library, and made sure the versions match across all projects in the solution.
In addition to Apache's and Steve's suggestions, I'd also recommend deleting the files in your Temporary ASP.NET Files directory. If you're curious here's a good write-up of what the contents of that folder are for.
i have an issue with the old setup projects in VS2010. please don't blame me for using that. it's a company decision which cannot be changed. poor enough i HAVE to deal with it.
i think it's quite usual what we got: a solution with some projects. the projects reference assemblies. some of them are 3rd party components. they are ALL referenced to/from the SAME individual folder (NOT the GAC or something like C:\Programs...). we just don't reference the installed versions. we want to keep them all in one place.
here comes the point... the project itself points to the folder we want. building and running is fine.
when i examine the setup project, SOME of the 3rd party assemblies are taken from our specific folder, others are taken from C:\Programs...
i just don't know why. i cannot influence this as it seems. even manually editing the .vdproj file ( were "GAC:FALSE" can be set) doesn't help! we need to reference the specific *.dlls in our folder.
has anyone an idea on this? i haven't found something so far...
cheers!
jens
This is how VS behaves. Even though you told him to search for your 3rd party dlls in your own folder, if it finds the same dll in GAC, it will reference it from there. On computers that do not have the dll in the GAC, it will reference it from your folder. In other words, if the computer you deploy your application has all the 3rd party assemblies in the folder that you referenced them from, and the folder exists on the target machine, the application will not crash, even if the dlls are not in the destination you see on your own machine, and will use the assemblies from the folder.
Maybe somebody fiddled with the default reference paths in Visual Studio. If you look at this article, about half-way through it explains the registry keys that are used to locate referenced assemblies:
http://msdn.microsoft.com/en-us/library/wkze6zky(v=vs.100).aspx
I think that the VS search mechanism will go through this list at build time, and you may end up with a rather strange combination, especially if some assemblies have dependencies on others and the assembly versions are different. So if you start with a certain assembly that requires others with a particular version it will chase that list of directories until it finds them.
I don't believe it is correct that VS will get assemblies from the GAC by default for reference purposes. The .NET runtime will do this when you run the program, but at dev time all the MS assemblies, for example, are referenced from the SDK install, not from the GAC. The GAC is a repository for running programs that require those assemblies, not a reference for dev builds.
I found posts mentioning issues with DEVPATH and webapps and I think MVC falls under this same band-wagon.
On my local PC; in one instance I need to be able to design and test our library of dlls; on another, I need to use these dlls, in various websites. Due to the number of sites we handle, we are looking at storing the dlls in the GAC in an attempt to avoid duplication.
When I want to work on the library I need to remove all the dlls from the GAC and then re-install them again once I have finished my development.
I have everything set as defined in various sources to make DEVPATH work, but it isnt working for me in my MVC project.
Is it possible to have dlls installed in the GAC, but run an MVC project that uses the DEVPATH copy.
I'm not having a lot of luck finding anything on the subject, but I am hoping it is possible.
Finally got a work around, it was quite obvious now I have done it.
It is a bit of work, but it does mean you can debug a website.
Also, it isn't using DEVPATH still, but it works so I am happy.
The main assumption I made was that the GAC always wins, even if you physically copy the dll to the bin the GAC will find the file first and use that reference.
So, the way I have found to work with local files (especially when I want to be debugging a website), is to change the assembly version number of the projects I reference to a new number. As this version doesn’t exist in the GAC, the Visual Studio webserver(cassini?) and iis web servers will use the local dlls. So any breakpoints I had added to my services etc. will then be picked up.