I have duplicate assemblies with different versions. I cannot recompile projects that use old versions of the assembly, so I manually copy the assemblies into a sub directory of my bin folder, then update the web.config with assemblybinding's.
This works fine, but now I am trying to add the old assemblies to the visual studio project so that they will be deployed to the build directory. But, visual studio keeps looking at these assemblies and telling me I have a version conflict! Therefore, I cant compile the project...
You cant have the same assembly referenced twice in one program, even if they are different version, it's just the way visual studio works. You need to reconstruct and recompile the code that references the older assemblies using the new versions of the assembly. This can be done via a reflector, and is relatively easy if you know what you are doing.
Related
I've got ProjectA. It has a WinForm and some .resx files in it. I created a Shared Project (ProjectA-shared) and moved everything to it. ProjectA references ProjectA-shared.
When I compile the Solution with VS2013 and the Shared Project plug-in, I get the following exception when running the app:
Could not find any resources appropriate for the specified culture or
the neutral culture. Make sure "Foo.Controls.MyForm.resources" was
correctly embedded or linked into assembly "Foo" at compile time, or
that all the satellite assemblies required are loadable and fully
signed.
When I compile the Solution with VS2015, everything is OK.
I am now left wondering:
Why would there be a difference between the VS2013 and VS2015 outputs?
It looks like .resx and WinForms aren't a natural fit for 'Shared Projects': what is the best way to share this kind of thing between two projects (primarily, projects using Shared Project just so that they can target .NET 4 and 4.5)
In previous versions of Visual Studio (from VC6 up to VS2008), we have had the convention of putting a "D" at the end of the names of debug-build DLLs, as is done for MFC and the CRT libraries. So, for example, if the release-build DLLs are "foo.dll", "bar.dll", and "baz.dll", the debug-build names are "fooD.dll", "barD.dll", and "bazD.dll". This prevents us from accidentally mixing release and debug DLLs.
However, we are having trouble doing this with the new C++ build system in VS2010. It worked with the dependency-based system in older releases, but now project references are apparently based upon the target DLL name, so it seems that they have to be the same for both Debug and Release builds.
The obvious solution is to just abandon the debug-build suffix, but we'd prefer to keep it if possible. Is anyone else doing this, and have they figured out how to make it work with VS2010?
BTW, I ran across Using Visual Studio project properties effectively for multiple projects and configurations. I'll have to review it with other team members to determine whether it might solve our problem.
In VS 2010 express there are a few library projects (dlls) attached to the application project. When building the solution the dlls output to bin/Release/. Is there a way to have the .exe output to bin/Release and the dlls to bin/Release/dll?
This requires either a .config file with the <probing> element or implementing AppDomain.AssemblyResolve so that the CLR can find these DLLs. You'll have a deployment problem too, you have to convince ClickOnce to publish these DLLs. Realistically should only attempt this with the retail edition of Visual Studio so you can create a Setup project.
Fwiw: your customer won't mind that the DLLs are in the same folder as the EXE. I think most actually strongly prefer this. I do.
You could always have a post build event on the application project that copies all .dll files to a dll directory.
However the assembly loader will not be able to find the dll file and you application will not start.
In our company we have got a custom library. We are using it in most of projects and our library is still developing. So sometimes we had to build and generate new assemblies twice or more in a day.
We were using GAC to store our custom libraries assemblies. As you guess replacing GAC with new assemblies become boring.
For this reason we decided to create a folder in solution that name is Referenced Assemblies and created a Solution Items folder and added assemblies this solution folder. So when we Get Latest from TFS we can get new versions of assemblies. This is more easier than GAC (but in theoratically)
When we started to use; problems became clear. For example sometimes Visual Studio marks DLL "delete,lock", despite not delete. Or sometimes when our team members open a form, designer throws exception because of could not find releated classes in assemblies. We had to rebuild solution or restart Visual Studio for several times.
Storing assemblies in GAC or Referenced Assemblies folder has a common problem. You need to put new assemblies somewhere to share other team members. For example, if assemblies stored in GAC, they can share via UNC, else if assemblies stored in Referenced Assemblies folder, new assemblies had been copied to other projects which required.
What is the best practices for storing referenced assemblies in a solution?
We ara using VS 2010 and TFS 2010.
Our projects framework version is 3.5
Take a look at NuGet / NuPack
http://www.hanselman.com/blog/IntroducingNuPackPackageManagementforNETAnotherpieceoftheWebStack.aspx
http://weblogs.asp.net/scottgu/archive/2010/10/06/announcing-nupack-asp-net-mvc-3-beta-and-webmatrix-beta-2.aspx
This is similar to Add Non-GAC reference to project but the solutions presented there don't seem to help.
I have a WinForms UI Library (Krypton from ComponentFactory) installed in the GAC. There's a bug I want to track down in that library, so I added the source code to my solution, removed the old references from my WinForms project to Krypton DLLs, added them back as a project references, ensured Copy Local is set to true, double-checked that the path (on reference properties tab) points to my local project, and...
...the GAC version is still being used while debugging. I cannot set a breakpoint in the Krypton source, Debugger.Break() or other code changes to not execute, and when I start the Visual Studio 2010 debugger, I see a Loading from ... GAC_MISL message relating to the Krypton DLLs flash by in the VS 2010 status bar. The DLLs are not copied to the WinForm's Debug folder.
How can I reference the "project" version of the files while debugging while leaving them registered in the GAC?
The CLR will always look in the GAC first. Don't hesitate to use gacutil.exe /u to remove them. Hacking the [AssemblyVersion] would work too so that the GAC copy won't be a match.