During development of the ConSense Cockpit solution? I experienced (see 348) a problem when deploying a Windows Presentation Foundation (WPF) solution on a target client with no XNA (btw - an extremely lame acronym from Microsoft) installed which resulted in:

The specified module could not be found. (Exception from HRESULT: 0x8007007E)

For me the trick was to include the libraries:

1.  d3dx9_31.dll
2.  msvcr80.dll
3.  X3DAudio1_4.dll

in the solution project and have them copied in a post-build event to the deployment folder (/installDir).

Due to the surely incoming copyright and litigation infringements I hope you understand I just linked the respective google queries instead of uploading the dll's myself ;-(

Apparently you can use  DSOfile for Open XML documents, but at least for me there were problems in x64 environments - see  Stackoverflow: Unable to read Office 2007 doc props using x86 dsofile.dll on x64 system: In this 64-bit environment, DSOFile.dll can successfully read properties from Office 2003 documents (eg. DOC), but in the case of Office 2007 documents (eg. DOCX), only empty strings are returned for all properties, or else an error is generated.

So - use the  Open XML SDK 2.0 for Microsoft Office. After downloading and referencing the dll:

using DocumentFormat.OpenXml.Packaging;


WordprocessingDocument document = WordprocessingDocument.Open(filePath, false);
            
PackageProperties standardProperties = document.PackageProperties;

CoreFilePropertiesPart fileProperties = document.CoreFilePropertiesPart;
            
ExtendedFilePropertiesPart extendedPropertiesContainer = document.ExtendedFilePropertiesPart;
if (extendedPropertiesContainer != null)
{
    var extendedProperties = extendedPropertiesContainer.Properties;
}
            
var customPropertiesContainer = document.CustomFilePropertiesPart;
if (customPropertiesContainer != null)
{
    var customProperties = customPropertiesContainer.Properties;
}

Just posting this as it would have saved me some time myself back then:

In the  ConSense Prototype I have some custom libraries (especially the proprietary RDF-framework) which are used in multiple application-solutions (WPF Cockpit,  VSTO Plugins, Windows/WCF Service, Plugins for those Service etc..).

So - even if you use Subversion this still leaves the question open how to keep the libraries in sync, assuming they are included in multiple Visual Studio solutions and potentially simultaneous changes before a check-in can occur.

The solution for me - and I hope you allow some advertisement for a commercial software here - was the combination of  svn:externals and the  VisualSVN Visual Studio plugin.

The libraries are kept in a separate directory in subversion and referenced as an external in the "main" application's subversion properties:

Select the application directory in subversion (Tortoise -> Repo-browser) and in the properties section (right click on the directory and select properties) add a new key "svn:externals". The value looks something like

Externals/ConSense.Generic.Rdf http://subversion.consense-project.com/2_Generic/ConSense.Generic.Rdf

with the first part being the directory the external sources will be included in in your application solution upon checkout and the second being the svn-path to the external. When you now checkout the application using VisualSVN the library source files are automatically checked out as well in the (above screenshot: /Externals/) directory you specified as first parameter in the properties.

The only caveat is that the global checkout-button of VisualSVN does only checkout the main solution, not the included externals so additional manual checkouts (right click on the external-project --> subversion --> checkout)are needed.

This may be blatantly obvious for most developers, but just to save someone the time to figure this out by himself: To attach the debugger to your process put some sleep into the service's Main method so you got enough time to attach before whatever may be causing an exception

System.Threading.Thread.Sleep(10000);

Requirement: I want a Windows Service

• under LocalService (and not LocalSystem see  Microsoft MSDN: Secure Hosting and Deployment of WCF Services )
• using Log4Net starting when the service's Main() method is called - so I can see if the service starts up at all

Seems easy, but wut - no logfile created!

The help at  Apache FAQ: Why doesn't the logging in my service work? is fine, but maybe I just skipped over it - it took me a while to figure out that the problem of log4net not showing any results (meaning: writing out a logfile) was related to the windows service not being able to find my application.config file (cause the service was called from a different location than my output dir).

The Apache FAQ suggests using AppDomain.BaseDirectory which unfortunately fails when I want to initialize the logger in the Services Main() method due to Main being static. Copying the app.config to lets say c: and using

log4net.Config.XmlConfigurator.Configure(new FileInfo("c:\\app.config"));

works, but isnt exactly what we want - at least it should use some temporary or application-specific dir in %appdata%

edit: time to bang head against something again - a failure in the configuration file caused the problem.

This line allowed logging to a client-specific directory:

<file type="log4net.Util.PatternString" value="%env{APPDATA}\\ConSense\\Logs\\ConSense.Sensors.Service.ConsoleStart.Log.txt" />

Btw - a very nice introduction to Log4Net:

•  beefycode.com: Category Log4Net