I have a dll project built with VS2008 (amd64). The manifest of the dll say
<assemblyIdentity type='win32' name='Microsoft.VC90.CRT' version='9.0.21022.8' processorArchitecture='amd64' publicKeyToken='1fc8b3b9a1e18e3b' />
When I load the dll into DependencyWalker it refers to winsxs-directory
amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_08e61857a83bc251
How can that happen? Isn't this whole manifest-thing meant to avoid situations like that by giving every dll/exe the information which version it is built with and therefore the CRT-version it depends upon?
And the second, even more confusing thing is that the msvcp90.dll depends on msvcr90.dll but the msvcr90.dll cannot be found!?! Hey, it's in the same winsxs-directory together with msvcm90.dll and msvcp90.dll!
If I copy the right msvcr90.dll in the same directory as my dll it works! (But again, isn't that the situation we had in DllHell times? And shouldn't that msvc*.dll-copying should be over since we have manifests???)
I would be really grateful if anyone has an explanation for me!
With manifest, Microsft had introduced a new kind of "dll hell" to resolve "dll hell" :(
By the way, the last version you are referencing (9.0.30729) is the MSVCR9 CRT upgraded to SP1.
May be you could try to update your VS2008 with this version to "synchronize" the manifest.
Related
I am using the log4net dll of version 1.2.13.0 built using the old key. I didn't find the version of log4net.Ext.Json to be used with this version of log4net. Could you please help? Also, after referring the md5 of log4net-1.2.13 here, I couldn't locate any of the md5 specified on the wiki.
Are you still in need of that fix?
You could possibly build it from source
Alternatively, I'll suggest moving to new-key log4net if you can. (I guess you've considered that, alright :o)
I'm quite new to MVVMCross but I've been actively using it for two weeks, at work and in a school project, and I am really enjoying it! Unfortunately, I've been stuck on the school project for 2 days now : we're asked to do a mobile Jabber client. This is not a big deal since I started it using Matrix XMPP library, which does most of the job and is easy to use. I decided to restart my project using MVVMCross, in order to have cleaner separated code and add a Windows Phone project, but Matrix absolutely needs System.Xml.Linq, and I can't get the core PCL to compile :
The type 'System.Xml.Linq.XElement' is defined in an assembly that is not referenced.
You must add a reference to assembly 'System.Xml.Linq, Version=2.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
As shown in Stuart Lodge's tutorial videos, I'm using profile 104, the the faulting dll is really present in the folder, I can't add it manually to project's references since VS prevents me from doing it (gently explaining that it's automatically loaded since .Net portable subset is included in references), I've updated and repaired my VS install "just in case"... and have no more idea left.
So, here are the questions :
is it really possible to use System.Xml.Linq with MVVMCross? or did I miss the big title explaining that what I'm trying to do is stupid?
if yes (that'd be great!) did/does someone experience the same problem? Even more interesting : did someone find a solution?
Thanks in advance!
Additional info : Windows8(x64), VS2012 Ultimate, trial license (school project...) for Xamarin.Android
UPDATE : following Stuart's answer, I compiled and ran the BestSellers sample, which uses System.Xml.Linq... without any problem. As it comes with an explicit reference to System.Xml.Linq (see first link in answer), I tried :
to delete it (and a few others) : VS holds it's promises, and really includes needed references as long as .Net Portable Subset is referenced, so everything rolls smooth.
to manually add this reference via Notepad to my .csproj : it doesn't change anything.
One thing tickles me in Stuart's answer : "perhaps it is something to do with the way the matrix uses XML.linq". Since the Matrix type I'm trying to use is just a descendant of System.Xml.Linq.XElement, which is widely used in BookViewModel.cs from sample, what could possibly be wrong with that?
"Solution" : The problem seems to be due to Matrix requiring a special version of System.Xml.Linq, which is not the one included when profile 104 for building PCL. I used file linking method as a workaround to share the core, and that works, though this is less elegant, readable, and harder to maintain...
Yes it is possible to use at least some of System.Xml.Linq
For example, see the BestSellers sample
csproj file - https://github.com/slodge/MvvmCross-Tutorials/blob/master/Sample%20-%20BestSellers/BestSellers/BestSellers/BestSellers.csproj#L49
example XML linq use - https://github.com/slodge/MvvmCross-Tutorials/blob/master/Sample%20-%20BestSellers/BestSellers/BestSellers/ViewModels/BookViewModel.cs#L44
For the problem you are seeing, I'm really not sure what the error is - perhaps it is something to do with the way the matrix uses XML.linq? You might have more luck of you open up this question to other tags like portable-class-library, XML-linq and windows-phone.
We have a group of developers moving from C++ to C# and WinRT. We used D'Oxygen as part of our C++ developer builds, and I'd like to continue to have document generation as part of the developer build in C#/WinRT.
It's easy to turn on XML Doc generation, and I believe that will provide warnings for malformed tags, but without actual HTML output, I think our developers will be missing valuable feedback.
Looks like NDoc is now defunct, and I took a quick look at Sandcastle, but found it rather complex. Ideally, I'm looking for something that doesn't unduly burden developers, or require them to remember extra steps as they edit, build, test, and commit. In other words, the best solution would be something that "just happens", like a post-build step, and doesn't add significantly to each developer's build time.
If anyone has had some experience doing this in C#/WinRT, I'd sure like some advice.
Thanks in advance!
Get Sandcastle Help File Builder.
Create a help project for your library in the Visual Studio solution.
Remove Build check mark from Debug solution configuration to build the documentation project only in Release configurations, since Debug is most often used during development. For release build testing or performance testing you can either create another solution configuration or simply switch the option back and forth.
Build the documentation once
Include the documentation file in the solution so it shows up in the Pending Changes window when the file changes.
Kindly ask your developers to build with the release configuration that updates the documentation before check-in or use any other policy to require updating the documentation.
I don't think it makes sense to build the documentation all the time, but it helps to make it easy to do so that when you actually need an updated version - you can build it really quickly.
You can also make sure to use FXCop or StyleCop (forgot which) and configure it to treat missing XML documentation warnings as errors - at least in release builds. Doing it for debug configurations might slow down development and make changes difficult since developers often want to try things out before committing to a final implementation worth documenting.
EDIT*
Sandcastle provides various output formats as shown in the project properties:
I would like to mention ForgeDoc (of which I'm the developer), it could be what you are looking for. It is designed to be fast and simple, and it generates proper MSDN-like HTML output. It also has a command-line interface so you can just call it from a post-build event command in Visual Studio.
I think you should give it a try, as I would really like to hear about your thoughts.
I want to run Nuint in Visual, so I set
<StartAction>Program</StartAction>
<StartProgram>$(NUNIT_PATH)\nunit.exe</StartProgram>
<StartArguments>Test.dll</StartArguments>
<StartWorkingDirectory>Test\bin\Debug</StartWorkingDirectory>
in my csproj file. But it stll does not work.
Those entries look correct for the project file. The most likely cause of the problem is that $(NUNIT_PATH) isn't properly set and hence gets evaluated to nothing. This would cause Visual Studio to look for nunit.exe in the Test\bin\Debug directory.
To test this try hard coding the full path to the nunit.exe binary into the file.
<StartProgram>C:\the\path\nunit.exe</StartProgram>
If this works then the NUNIT_PATH value isn't properly set.
Unfortunately the Express editions don't support the StartAction mechanism. See MSDN How to: Change the Start Action for Application Debugging.
I'm looking for alternatives though ;-)
Update see also SO-a/10572249/717355: Try http://www2.wealth-lab.com/Wiki/kbDebugExpress.ashx step 13 for a suggestion on making MSVC think its debugging your code directly. - Untried.
Which of the hg plug-ins has:
the least hassles
causes the least trouble
is prettiest
Can't claim to have tried a wide variety, but, what's wrong with hg4idea...?
In regards to the "don't use one" response - this is hardly adequate. What if I use my IDE to do a refactoring that renames a file? Without IDE/source control integration, the file rename is made without regards to source control, and then Mercurial (or whatever else) thinks a file went missing and a new one appeared. Then you have to go back to wrangle with the source control to sort things out.
JetBrains seems to have chosen hg4idea-luciad for its upcoming Python editor (PyCharm) and it is now more active than hg4idea
It looks like a leader is on the way :-)
To answer your question: The best IDE PlugIn is don't use on.
I think IDE integration is not necessary when working with a DVCS. When working in a centralized System, it is reasonable for the purpose of automatic check out on edit. However, I like keeping things separate. I don't want my IDE cluttered up. I don't see any benefits in using a plug-in compared to a standalone solution (that I keep running on a second monitor etc. ).
I am fine with TortoiseHG and the command line for more complicated tasks.