Installation of Dynamics NAV 2009 hangs during installation of Outlook Add-in
When installing NAV 2009 RTM you can sometimes if you are unlucky end up with an installer that hangs when installing Outlook Add-in. The most common reason for this is that the installation is not able to update the” Outlook.exe.config” file and get stuck in an infinitive loop.
When looking in the event viewer you will get a similar error message to this:
Product: Microsoft Dynamics NAV 2009 Outlook Add-in — Error 27519.Error updating XML file C:Program FilesMicrosoft OfficeOffice12Outlook.exe.config. -2147024891
Read more
WPF Application Quality Guide v0.5 has been released
WPF Application Quality Guide v0.5 has been released today at the WindowsClient.NET with new topics and updates.
This release includes several new additions and updates:
1. Suggested Roadmap – updated to include new topics based on different persona
2. Performance and Scalability Testing – updated with a few new resources
3. Integration and Scenario Testing – a new article outlines the strategies and the steps to take in Integration and Scenario testing.
4. TestApi (Tools) – updated with summary of the new APIs from TetsApi v0.2 as well as sample usages.
5. Tools – various new additions and updates to commonly used tools.
6. A1 Building a WPF Application Test Suite by Using VSTS, NUnit, or xUnit – a new article summarized the common unit testing frameworks including sample test code and key resources.
7. A4 Considerations for WPF Browser Applications – a new valuable write-up with common considerations in XBap apps.
Using SQL Server 2008 Express in Dynamics NAV 2009
NAV 2009 will install SQL Server Express 2005 by default if no SQL server is installed. So if you would like to use SQL Server Express 2008 instead, this is the way to go:
The Demo installation of NAV 2009 is looking for a SQL Server instance called MSSQLSERVER. If the installer can’t find this instance SQL Server Express 2005 will be installed and the Demo Database will be attached to SQL Server 2005 even though you might have had SQL Server Express 2008 installed.
So to install on SQL Server Express 2008 you need to set the instance name to MSSQLSERVER. This way NAV 2009 will install the Demo Database on SQL Server 2008.
Note: SQL Server 2008 requires the following:
.NET Framework 3.5 SP1
Windows Installer 4.5
Windows PowerShell 1.0 (Included in Windows Vista SP1 and Windows Server 2008)
Strong name versus certificate signing
When I have been looking around on the net about strong naming and signing I have found some confusion about the purpose and the difference between does two methods.
Strong naming
Strong names make names cryptographically strong. When you load banan.dll by its strong name you are saying “load banan.DLL which was signed by XCompany”. The loader verifies that the named dll was signed with the correct key, and if not the loader will refuse to load the dll. This is the only thing that strong naming does (making the name of a dll cryptographically strong). Strong names are not a mechanism for expressing trust decisions. Strong names are just about making a name stronger so that you have a guarantee that the code you are loading at runtime is the code you compiled against. That is the ONLY thing you can safely use a strong name for. Strong name keys go into a “snk” file, which you then typically include with your project.
Certificates signing
Certificates signing are completely different. Certificates form a chain of trust, where a trusted root certificate (Verisign, for example) is installed in every user’s root certificate store. Those trusted root certificates are then used to certify the identities of organizations that issue code signing certificates. This enables the customer to setup trust policies. For example, they can say “I want to trust anything that comes from XCompany”. How will they do that? They first check to see if the dll was signed by an XCompany certificate. But how do they know that the XCompany certificate actually came from XCompany? Because Verisign says so – Verisign signed the XCompany certificate saying “we certify that this dll signing certificate actually came from XCompany”. Why do they trust Verisign? Because Verisign is part of the Microsoft root certificate program. Acceptance into this program means Microsoft trusts these certificate authorities and places their root certificate in the Trusted Root store on Windows machines. That’s the root of the chain of trust. Certificates doesn’t go into strong name key files, they go into the operating system’s certificate store.
Microsoft Certified Professional Windows Developer
After been spending some tuff days with only reading about user cases and different deployment ways I have finally passed the windows MCPD exam. This is the exam that I think I did learn less from out of the 3 you need to get a MCPD for windows. It was a lot about user cases and testing that I did know most of it already trough my work and universities studies. So I guess the exam was more for people that would like to have paper that they know this things of have not any university degree in computer science.