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.
Related
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.
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.
We are working on a .NET application and recently started using Git for version control.
Our latest release was tagged in Git, and now i am trying to debug some issue.
Here's what i did:
Installed the app (from the release) on my Pc.
Checked out the tagged release version.
Started VS and attached to the process.
Placed breakpoints over some part of the code.
I am getting the message: "Source code is different from original version", however this is the actual code that was compiled to release this installed version.
What am i doing wrong here?
using VS2008 if that matters.
BTW: What is the mechanism that is used to compare if the binaries are different from source code?
When cloning the repo from Git, for example, it will change all files/folders date to the current date. Is this value (datetime) used to determine source code vs. binary?
The problem was i didnt use (or store) the original symbols for this release.
I previously thought symbols only contained source code line information and were not needed to actually debug the program under VS. apparently i was wrong.
A good resource on symbols for anyone who's looking into problems with them: http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/05/11/pdb-files-what-every-developer-must-know.aspx
This post also contains a few other links to MSDN Magazine with more valuable information.
I'm not sure if this problem is connected specifically with log4net or this is some problem with VS.
Everytime I'm trying, I have the same result. But let's start from the beginning.
I'm creating a simply console application (.net 4) and using nuget to install the log4net library.
Now, when I want to add some code from it, intellisense works ok:
But when I try to compile it, I have an error
This is the only one assembly I found to this moment, I have this problem with. I have absolutly no idea what (and why) is going on. I have checked with two other solutions and problem is the same. I have not checked manually downloaded version yet.
Most likely there is an underlying dependency that is missing. One very common reason is the project is using the Client Profile instead of the full .NET 4.0. (Not sure about log4Net, but I run into this a lot when including third party libraries, esp. those with ties to the web). If I am correct, simply going into properties and changing the framework version to full .NET 4.0 will solve the issue.
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