I want to develop a software which accepts the extension like that of Visual Studio Code. For example Software S has default functions f, then the extension e will help add new feature which will extend the functionality of the software. I searched for tutorials but I was not able to come up with the solution nor a good tutorial. Am I not searching with right tutorial? Please help.
"Copy Local" when set to true ensures that the dll for the assembly reference is added to the referencing project's bin folder so that it's available at the run time. If the required dll is not found in the bin folder then, the one in GAC can be used. If even then, the dll is not found, we will encounter errors.
If the same version of the dll exists in bin as well as GAC then, the one from GAC is used but if a different version is used and referenced in the project then the one from bin gets used. Similar question answered in Dll in both the bin and the gac, which one gets used?
Related
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'm working on a Web Application in Visual Studio 2012 using HtmlAgilityPack. My project references the 1.4.0.0 version of the dll in the application's bin folder. Previously it used 1.3.0.0
The application works, but about once a day the dll in the bin folder is overwritten replacing version 1.4.0.0 with 1.3.0.0. I've already checked the GAC and deleted my ASP.NET temp folders the first time this happened. Does anyone know what's going on here?
You need also delete the 1.3.0.0 dll from you solution's reference list from Solution Explorer.
The older .dll is apparently being referenced from somewhere within your solution. I would open the project file(s) in an editor and look for any references to older versions there.
If none are found, my guess would be that some other library or component you are relying on is referencing the old version of the .dll (are you using any third party libraries?). If you don't have the source for these, then perhaps you can decompile them using JustDecompile or some similar tool. Then you can at least check the references within the dll's your using, and confirm or rule it out as the source of your problem (no pun intented ^^).
Oh, and one more thing - maybe obvious, but have you set Specific version = true for the reference?
I have a solution that contains a C++ DLL project, and a C# project that will use this DLL (by using PInvoke).
The dll is being built to the x64/Release folder in my solution folder, which makes sense, because that way the C# project doesn't have to poke into the DLL project's folders.
I wonder what would be the correct way to reference it now though. Right now, the DLL project is a dependency of the C# project. My intuition told me that that should have been enough, but the C# project says it cannot find the DLL.
Should I just add the .dll file as a reference too? I thought this might work now but break things in the long run when project settings might get changed around.
I've answered a similar question before. So I don't repeat the text here.
You might want to take a look of:
When using open source libraries, should we compile against the source or the binaries?
Wish that helps.
Usually in such situations I configure my solution such that all projects compile to $(SolutionDir)bin\$(Configuration). The binaries are then located the same way as in production mode and DLLs may be easily used.
As for keeping the latest version of DLL, remember, that you may set a dependency, such that if anything changes in DLL, it will be rebuilt prior to building your assembly / application.
Yet another way is to use build events (prebuild and postbuild) to copy your DLL into appropriate folder.
You can not add an unmanaged DLL as reference in a managed project. The DLL needs to reside either in the executable's folder or in any other folder of the system's PATH.
The best way is to use a "Post Build Event" to have VS copy the DLL into the folder where it is needed every time it is rebuilt.
I'm developing a series of plugins for a 3rd part application, and the vendor gives us all of their plugin assemblies along with some helper assemblies for working with their system.
Our code usually references these helper assemblies, but the their plugin assemblies still need to be copied to the external bin/debug or bin/release directory. Normally I would make this a post-build event on the main project, but since this project is a collection of individual projects with their own dependencies I am not sure what to do.
What are some recommendations (or best practices) for handling this situation in Visual Studio?
Add the DLLs to your project in a folder with a descriptive name (libs, third-party etc...).
Set the Copy to Output Directory property on them (F4) to Copy if Newer or Copy Always.
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.