Posted by archworx on October 17, 2007
I got this error when I tried to use a C++ DLL, compiled by Visual Studio 2005 SP1, in a web application (ASP.Net 2.0):
“This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem. (Exception from HRESULT: 0x800736B1)”
This happens due to a lot of reasons, you can check them at: http://blogs.msdn.com/eldar/archive/2006/06/07/621501.aspx
The reasons in my case were:
1- The target C++ DLL depends on 3 DLLs: msvcm80.dll, msvcp80.dll, and msvcr80.dll version 8.0.50727.762. This is because the SP1 is installed on the development machine, while the production machine has these files but version 8.0.50727.42, thus, I installed Microsoft Visual C++ 2005 SP1 Redistributable Package (x86) on the production machine. You can get it from: http://www.microsoft.com/downloads/details.aspx?familyid=200B2FD9-AE1A-4A14-984D-389C36F85647&displaylang=en
2- My bad! I forgot to change the DLL’s active configuration to release, so you always have to check that before you deploy your application.
Posted in .NET 2.0, Configuration Management, El-Geish | 29 Comments »
Posted by archworx on July 5, 2007
Versioning is mainly used to identify multiple revisions of the same unit of information/code. Versioning is the corner stone of Software Development – it is used to differentiate between the different work you do everyday. If you do not version it is almost like you haven’t accomplished anything.
- RULE #1
- Version number should be stored in object code, for example a .NET assembly.
- This is so it can be accessed from the code itself. This is important because, for instance you can use it to gauge compatibility with other systems that you need to interact with. For example:
- If you are using a web service, there should be a way to query the web service’s version number from the web service itself. The Web Service itself may also need to know its client’s version numbers. With this information, you can programmatically control version compatibility, for instance the web service can deny the service to its clients because it knows that it is of an incompatible version.
- RULE #2
- Version Numbers Must be Unique and non-repeated.
- No two releases with any differences can hold the same version number. Even if it is just a minor bug fix. Even if it is a spelling mistake.
- RULE #3
- Version Numbers must be related to the Source Control Label/Tag.
- This works both ways, for example:
- The Source Safe label used in labeling a release should contain the same version number stored in the compiled binary, or part thereof.
- The Version Number produced inside the binary must be as closely related as possible to the label/tag name. Ideally part of the version number should be retrieved from the Source Control system. For example, using SourceSafe/KeyWordExpansion
- RULE #4
- Version numbers must be user accessible.
- Users of the application must be able to find out which version of the software they are using. Do not hide it from them, and make sure they can access it relatively easily.
- RULE #5
- Version numbers must be consistent across Configuration Items
- The version numbers stored inside the product binary must be the same as that reported to the user, as well as being strongly related to the source control label/tag name. The best way to achieve this is via a build control tool such as NAnt and/or Cruise Control for example.
More about Version numbers:
- Version numbers can look like x.x.x or x.x.x.x depending on mechanism or technology used.
Posted in Configuration Management, MZayet | 10 Comments »
Posted by archworx on March 28, 2007
You may need to add the enterprise library to GAC in case that you want to share it across more than one application in a production server, the enterprise library is a set of dlls, you should sign all those dlls in order to be added to the GAC. So, you should follow the following steps:
1- open the command prompt and type “sn -k c:\mykey.snk” to generate key file which will be used to sign the assemblies.
2- Open the enterprise library solution in the Visual Studio.
3- Open the Caching Project.
4- Open the GlobalAssemblyInfo.cs shortcut in the Caching project.
5- Add the following line [assembly: AssemblyKeyFile(“c:\\mykey.snk”)]
6- Make sure that you don’t have any “AssemblyKeyFile” attributes in the assemblyinfo.cs of each project, other wise you will get a compilation errors.
7- copy \Program Files\Common Files\System\Ole DB\oledb32.dll to c:\
8- generate the signed interop assembly using the following command: tlbimp /keyfile:c:\mykey.snk c:\oledb32.dll
9- the above command will generate “MSDASC.dll” which is the primary interop assembly for the oledb32 com
10- open the Configuration.Design Project
11- delete “MSDASC” from the references
12- add new reference to the generated signed MSDASC.dll
13- You must Compile the project with reference of the signed enterprise library dll’s in order to make your application can access the signed library from GAC.
NOTE: You must add the public key token used to sign the Library in the configuration file as dataconfiguration.config or the exceptionhandlingconfiguration.config or else you will get a security exception thrown in the log file and application will not work
Posted in Bubly, Configuration Management | 3 Comments »
Posted by archworx on January 22, 2007
Background: This post is about challenges in differencing binaries to identify if they are identical between assemblies on the testing environment and assemblies generated from code on SourceSafe. Read on for more details.
The Problem: At the end of your development efforts, you typically need to subject your code base to testing, and then upon testing approval, you ship your code to the client. However, bear in mind the following:
- Your Code Base is on a Source Control engine
- Your binaries are not – they are on the development and testing servers. It doesn’t make sense from a configuration management perspective to store binaries on source control (because:
- You can always generate them (theoretically) exactly from the source.
- It is a huge burden to ensure object/source consistency
- Even if you do keep them, you’ll have to check that the source & object are indeed consistent, which is an extra overhead)
- You typically need to ship to your client the binaries that are on your testing server – as those are the ones that have been approved by the testers.
- You can’t ship the source unless you are sure it generates the binaries the developers claim they have produced on the testing environment.
- So the obvious process is to retrieve your source code from your Source repository and recompile it.
Enter .NET Assemblies – which include the following obstacles to successfully being able to recompile the exact binary stream of code twice:
- By default .NET assemblies change their version # every time you compile – this is a good thing, as it provides for very good tracking of version numbers; something that is sadly lacking in many developer’s culture. However, this means that binary differencing will yield false positives.
- If you need your assembly to be hosted on the GAC, or otherwise want to sign your assembly, your assembly must be strongly named, this can pose challenges if you sign them with keys that are not controlled properly.
- The assembly header also contains a field called the “MVID” – which is the Module Version Identifier. This field’s purpose is solely to be unique for each time the module is compiled. This is a rather powerful concept, in the sense that this is the first time I’ve personally seen the concept of someone wanting to distinguish a compilation instance from another one, irrespective of the code being compiled itself.
The Solution: This article is about attempts to solve the three aspects of the problem described above. At this time, we have a simple solution and a workaround for the first two – about the version and the signatures, and we have hopeful indicators that the MVID issue too can be resolved.
- Version Numbers – can be explicitly defined through the removal of the “*” sign for release builds. You can find this field in the assembly info.
- Strongly Named – let’s ignore thise case temporarilly.
- MVID – we believe this can be controlled via a compiler option – but I am yet to find it.
The rest of this post is mostly dedicated to discussing the MVID issue.
Intermediate Language Disassembly:
ildasm /text /all file.dll
The MVID is used by the .NET CLR to determine whether or not to reload the precompiled assembly data.
This is to allow caching such precompiled data, and consequently ensuring cache integrity.
This would imply that the MVID is only useful when precompiled information exists in the assembly.
Typically precompilation only happens when you use NGEN.EXE.
Consequently not generating an MVID or generating it with the same ID is not necessarily a dangerous idea to contemplate.
Emperical Observation has shown that Nant manages to automagically generate the same MVID each time it recompiles, thus dispelling the myth that it must be unique for every ”compilation”. There must be a way to mimic Nant’s communication with the C# Compiler, as it must be using it to do the compilation. There is no way that Nant is faking a compilation. Or is there? 😉
The observations proposed herein are very encouraging, even in so far as they encourage extreme ideas, such as:
1. manually coercing the same uid value for the mvid for otherwise identical compilations (via injecting it into the binary for example); because this would theoretically not jeopardize the sanity of the ngen-generated data.
2. We could do a manual textual comparison of the assembly’s code via ildasm /text and a script that conceals the mvid information
More on this later.
Posted in Configuration Management, Continuous Integration, mkaram, Source Control Tools | 13 Comments »