I am using a third party software in my C# VS2010 project. I am gettong a warning to remap three of their assemblies.
How do I do that? I have no clue and searching through google i come across how to remap specific MS assemblies and it is much more complicated that I need. I just need to remap their version number.
I just want to know an example that shows what is the simplest way of remapping any assembly?
Any help is very much appreciated.
This ended up being a "DLL Hell" kind of issue and I did not have to remap the assmeblies just looked through my machine all over and got rid of the specific dlls wherever they were (whether the buidl code had put it there or myself).So I cleaned all DLLs up, then copied the latest versions to where the build needed them.
Related
I am trying to use Microsoft´s WorldLockingTools (repo see here) in my Unity Mixed Reality project. Therefore I need to add the Frozen World Engine DLL to my Unity Project. In Microsoft´s Documentation they describe to do this via nuget. I want to add the dependencies manually like described in this thread, since for me it´s not possible to use nuget (I have no network-access on that computer). I was able to extract the .dll, but if I add it to my project as described in that thread, unity still can´t find the dll. Do I need to do some further steps than just adding the dll to my Asset-Folder? If yes, can you please tell me which steps they are? I would be really thankful for that!
Best regards!
OK I figured out the reason behind this misbehavior. The problem is, that there is a c#-Script within the nuget-package additional to the dlls which has to be placed within the WorldLocking.Engine folder. After that all Exceptions disappeared and it seems to work now! I Hope I could help anybody who comes across this Question.
from here, I want to download GDAL library. I mean I want to download .h, .lib, .dll files. I'm working in visual studio 2010 and using visual C++:
Solution Configurations : Debug
Solution Platforms : Win32
In fact I don't understand what's the difference between Developement and stable libraries?
And which one should I download?
Even I don't know what other information you need to post here?
The "stable" library is one that's been tested so they believe it to be reasonably bug-free.
The "development" library is one they're currently working on. It's probably had some new features added. It may also have had some bugs added, the documentation may be somewhat out of date, etc.
As to which to download: especially at first you typically want the stable version. It has a much better chance of working as documented (and, for that matter, of just plain working).
The development version is primarily for one of two situations: either when/if you think you might want to contribute some work to the library itself, or if it includes a new feature that happens to be really crucial to your work, so you're willing to put up with possible shortcomings elsewhere to get that addition.
This isn't really coding specific, but we currently have a project that is live and working fine. I am tasked with making a few changes to it. I imported the ALL files of the project to Visual Studio 2010. I can't get any work done, because of all the errors!
Do you have any suggestions for me? The project doesn't have a source file, so I created a project and made one myself.
I tried another version of Visual Studio, and the errors continue. How in the world is this project even working?
Also, I have no way to speak with the creator.
Thanks for the help!
Josh
Without seeing the specific errors you're running into, I'm guessing that you are hitting one of two scenarios:
The source code references .NET assemblies that you do not have installed on your development machine. The only way to correct this is to get your hands on a copy of those assemblies to install them. The assembly names should be in the error messages, which would give you a good starting point to look from.
It's also possible that differences in the .NET framework versions that it was originally developed in and what you are trying to use now are accounting for a large number of errors. If the errors specifically reference the version number, this is most likely what you're experiencing. If this is the case, there are ways you can upgrade the individual file versions that your program references, but I honestly haven't done that in about 8 years, so I'm drawing a blank at the moment as to how to do it.
I don't understand ?
you have a "project" (what kind of project?) that you want to start working with with VS2010 ?
You add the files to a new VS2010 project and start building it and many errors occur ?
What kind of errors ? Language (C++/C#) errors ? missing include missing ? missing libraries ?
Can you show a some of the errors you get ?
Is there a way to make visual studio not care about dll versions? Is this a bad idea?
I am resetting up my dev machine and I just installed the latest version of Pex and Moles (version .92). All my projects are on version .91.
We are in the middle of a release and don't want to upgrade right now. Also, I cannot find an installer to version .91.
When I try to compile I get a message that I am missing the reference. (Hence this question)
The version is important.. By definition, there is a difference from each released version to the next (or there would be no need for a new version). Your program may not perform correctly if you are expecting one version and instead have another.
This was a part of what was known as "DLL Hell" in the pre-.NET days... If you needed to use a third party component (Crystal Reports Viewer is one we always had to deal with), you would just use the reference to whatever installed version was on the user's PC. Our retail locations had to have a specific version of Crystal Reports for their bookwork reports to print correctly, and because of that, we had to hold on to an old version forever.. Upgrading Crystal on the PC broke the vendor's bookwork app. On my first ever PC, I had several applications break when I would install or upgrade another. In particular, Real Player broke my telephone answering machine software. Goofy stuff like that...
So, the version IS important, even if it is an annoyance. It's also why I have a bias against third party tools that I have no code for, and can't recompile myself.
If you look at the properties of a referenced DLL, you will see a property "Specific Version". If you set it false, it doesn't track the specific version in the project file.
For this to work, you have to somehow fix the references where ever they are used. You can do this by opening every solution and fixing the references (at which time you could also just update the references to the correct version, paying heed to David's comments).
If you have a lot of solutions, you might use a tool like sed (see this post for windows versions of tool like this Is there any sed like utility for cmd.exe) to just update the project files as needed all at once.
In Visual Studio 2003, you could easily set your project assembly to auto-increment every time you built it, but with Visual Studio 2005, this functionality was removed. You can still auto-increment your assembly version on every build, but it's a complicated custom build step instead of an integrated feature.
I'm not sure why this was removed, but here's a question I should have asked a while ago - Should I be using a workaround to continue to auto-increment when I build, or is there a good reason to stop doing this, in favor of manually incrementing? Since Microsoft removed it from VS, perhaps there's a good reason, and I'm wondering if anybody knows it.
No, auto-increment on the [AssemblyVersion] is supported in VS2005 and up. Make it look like this:
[assembly: AssemblyVersion("2.0.*")]
I have little use for this capability myself. [AssemblyVersion] describes the outward visible public interface for an assembly. That doesn't change when I simply rebuild the assembly. [AssemblyFileVersion] is appropriate for tracking build numbers. Sadly, it does not have the auto-increment capability. Note how the .NET assemblies use that version numbering strategy as well.
Also note this feedback item.
I personally prefer not to do it since I at the moment work on a project where I need to be able to know exactly what features where added to exactly what version and if it autoincremented every time I built it would increase too rapidly.
However, I think it depends on your project if the advantages outweigh the disadvantages. Here's an old MS Patterns page that discusses advantages vs disadvantages of the built in auto incrementation:
http://msdn.microsoft.com/en-us/library/ee817676.aspx