Could not copy the file manifest because it was not found

This is an old chestnut that has maddened me for quite some time. It all starts with the error message

• C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets(4453, 5): error MSB3030: Could not copy the file "bin\Release\myapp.exe.manifest" because it was not found. 
• Project src\mysolution\myapp\myapp.csproj failed. 
• Project src\mysolution\mysolution.sln failed. 

It almost certainly happens when you are doing the following:

• Using msbuild directly, rather than Visual Studio "right click" (e.g. you are using Team City)
• Have a solution with a web application and some other application types (e.g. a console app)
• Are using the Target "Publish" to publish the website

For example, here are the TC settings that cause the problem for me:

I'm also using a solution that has this structure

• MySolution
• MyConsoleApp
• MyWebApp

MyWebApp has a publish profile setup called "PublishToDisk". If I build or publish from Visual studio, everything is fine. If I build from Team City, I get the errors above.

I've known the cause of the problem for ages. The blanket "Publish" target is being applied to every project in the solution that might be publishable. That includes my console application. My console app is not setup for publishing however, nor do I want it to be. I do, however, want it to be built during the Team City process, as the app will get copied elsewhere via the packaging process in later stages.

However the possible solutions are not so obvious. running msbuild separately on myConsoleApp.csproj and MyWebApp.csproj seems ridiculously inefficient. Making my console application a click once app just to stop a build failure seems equally silly. By far the best solution I've found is to edit your myconsoleapp.csproj file and add the following section

<PropertyGroup>
    <GenerateManifests>true</GenerateManifests>
</PropertyGroup>

You can add this just before the ItemGroup for reference includes.

This should be enough to keep to allow your application to build without a load of very awkward feeling bodges.

Incidentally - this problem is one that occurs if you try to do this publishing process with Orchard via TC, so would solve that scenario too.

Going Native is All Too Easy

We tend to fall into the same traps over time, not matter how much we try. When I was a consultant, it was very easy to correct a client who demanded technical solutions instead of listing their business objectives. It was my job to re translate that back into "what is the real requirement here".

Now I've been working for an architect at a single company for two years, I find myself falling into the traps that I used to help others avoid. In designing a new profile service a group of three architects, plus other contributors discussed the proposed structure. We went over all the technical implications, and we felt we understood what the business need was quite well thank you, including what would need to be in an MVP, and what could be deferred to later.

Four months on and I find myself in a very enlightening meeting with key business users, who have a far better understanding of what they need than I did, despite having "done my research". I find that several of the decisions I made, while valid in their way, just didn't go far enough to addressing the business need.

It is a timely reminder that the developer (no matter how well in tune with the business he believes himself to be) is ultimately far more focused on a technical challenge and "elegant solutions" than he is with what the end consumers want.

Lesson Learned: If you think you have a solution to the business problem, ask yourself "have I sat in a room for an hour with four business user who have no interest in how it is done, but only what it lets them do?"

Pros and Cons: Comparing RavenDB and FoundationDB

We've recently been evaluating options for storage for a new profiles micro-service. The original prototype for this was produced in Raven, but recently other teams within the business have been having some level of success with FoundationDB. While RavenDB is touted as a "Document Store", FoundationDB claims to be simply a "Key/Value pair store. Below is my assesment of the pros and cons of each.

RavenDB

---

Pro

• Excellent .NET client API with extensibility points, providing easy developer learning curve
• Designed as Document Store
• Provides Index/Map/Reduce
• Stores natively as JSON
• Good Read Performance
• Fits excellently into integration testing, due to in memory db option designed for testing
• Automatically generates Ids for records
• Well presented web based management studio
• Raven Server has a good console where you can see requests/response times and what indexes are used to resolve queries

Con

• Cannot test replication, sharding or authenticated access functions without purchasing licenses and licenses are needed for anything other than development (UAT would need licenses)
• Some concerns over the dependence of the RavenDB project on one key developer
• Some concerns about the robustness of the testing of the product and its unproven track record in enterprise solutions (posts like this are easy to find
• Yet another product for devops to support
• Need to understand the “eventually consistent” model well when designing solutions

FoundationDB

---

Pro

• We already use it in several other services (we have experience of it)
• Better licensing terms (by far) All features free outside production, and production licensing terms essentially means it is currently free for us to use
• Full ACID compliance
• Has both Consistency and Availability during Partitioning (assuming it isn’t a catastrophic failure)
• Built in transaction retries
• Support from FDB team is excellent
• Excellent read performance both single reads and range reads are only marginally slower
• Transaction isolation level is serializable
• Simple to scale horizontally

Con

• Designed as a Key/Value pair store rather than Document Store
• Weak .NET support (only 3rd party .NET client wrapper on top of C) with less .NET documentation/support. NET not considered first class citizen of FoundationDB
• Constraints on deployment - cannot be deployed in IIS, must be self-hosted - loss of IIS specific features such as graceful request handling, automatic app pool recycles/mem management
• Cannot run in multiple AppDomains on same process
• Like Raven, also an Alpha product, though we have less concerns about the composition of the development team
• Does not generate IDs, so a separate “ID Generation Service” would be required (or switch entire platform to GUIDs with the resulting data migrations
• No nice ‘management’ interface - you need to roll your own admin tool

To summarise the differences at high level I would say that RavenDB is great for .NET developers to rapidly write applications against, but may provide a problematic operational experience, and paying before you can test replication/"clustering" successfully is a tough ask. Conversely, FoundationDB has a really steep curve to get going with .NET, you have to live without several normally expected comforts, but does provide a compelling operational case from the ACID/clustering point of view (though, it too is an alpha, but its testing thoroughness seems far better).

As for which is "better", well, it really depends on purpose. It looks like a case of weighing up "Fast, easy development" versus "fast easy ongoing operational support". As a business we are currently leaning towards the operational ease, as products tends to spend most of in production, not development (unless you are the UK government of course).