SharePoint Behaved Types - Run Pex Explorations error (System.Moles 4.0.0.0) - sharepoint

I was following a tutorial on pex and moles (http://research.microsoft.com/en-us/projects/pex/pexsharepoint.pdf). Its a year old, but everything worked fine until I changed Mole types to Behaved types. Once I did that, 'Run Pex Explorations' command started throwing this exception:
Could not load file or assembly 'System.Moles, Version=4.0.0.0, Culture=neutral, PublicKeyToken=0ae41878053f6703' or one of its dependencies. The system cannot find the file specified.
I tried multiple solution (including Moles and SharePoint Behaviour types). I also tried to generate Moles for System 4.0.0.0 assembly, but that fails with multiple 'cannot find suitable method to override' errors.
I'm using the latest version on pex (0.94) and moles (1.0.0.0). Is there any solution for this?

Just create a mole for System this way:
<Moles xmlns="http://schemas.microsoft.com/moles/2010/">
<Assembly Name="System" ReflectionOnly="true" />
<StubGeneration Disable="true" />
</Moles>

Related

Excel Type Provider has error - it needs an assembly "Excel.dll"

So, I started with this code:
open System
open System.IO
open FSharpx
open Excel
module ExcelManipulation =
type BoyICantWaitToUseThis = ExcelFile< #"C:\Users\sean.newham\Documents", "Sheet1", true>
let example = new BoyICantWaitToUseThis()
...but it doesn't compile because I need an "Excel.dell, Version=2.1.0.0...", I didn't know which Excel.dll that was, so I tried including the Excel Data Reader, which has a dll called "Excel.dll", but alas, this does not appear to have removed the error message.
Any idea what I need here and where I could get it from?
Thanks in advance
It appears that until about 5 days ago (see here), the excel type provider had a dependency on having Office installed with the office interop files. The newer version depends on the Excel Data Reader.
If you look at the pull request for that change here, you see that the type provider used to reference
<Reference Include="Microsoft.Office.Interop.Excel, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
See here for instructions on how to install that.
As an added bonus, you can look at the unit tests in that link for details on how to use the provider.
I was stuck at this same point trying to use FSharpx.TypeProviders.Excel. I switched to ExcelProvider and it worked out-of-the-nuget-box:
http://fsprojects.github.io/ExcelProvider/

Error Running Code Analysis in VS2012: Could not resolve type reference

When I click the Run Code Analysis project context menu item. Building starts, but stops with following error:
CA0001 Error Running Code Analysis
CA0001 : The following error was encountered while reading module 'EntityFramework':
Could not resolve type reference:
[System.ComponentModel.DataAnnotations, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35]System.ComponentModel.DataAnnotations.Schema.ColumnAttribute. [Errors and Warnings] (Global)
Analysis on other projects works well. How to eliminate this problem?
I tried the solution mentioned by Scott Wylie. I tried adding a reference to System.ComponentModel.DataAnnotations in my project but that did not help.
I then tried copying and pasting the System.ComponentModel.DataAnnotations.dll directly into my bin folder and that did the trick. Add the dll into your local bin folder, publish the solution, then manually add the dll into the bin folder of your published project (if it didn't copy up on its own).
The System.ComponentModel.DataAnnotations dll may not be used by your application but it is internally referenced by EntityFramework.dll. Code Analysis will look at all of your referenced dll's and try to resolve their references too. If you add the System.ComponentModel.DataAnnotations.dll to your application, this error will go away next time you run Code Analysis.

FxCop fails to analyse the indirectly referenced assembly

Metrics.exe: error: The referenced assembly 'Exception.dll, version=1.0.5289.9, Culture=neutral, publickeytoken=67er8..' could not be found. This assembly is required for analysis and was referenced by
\bin\cancel.dll.
But the assembly it is trying to refer to (Exception.dll) is GAC'd. i.e, present in the C:\windows\assembly.
I have around 300 project files.. Copying the assembly to each project will be a cumbersome process..
Is there any workaround?
*Important: Check the assembly versions.
The assembly Exception.dll was of an older version in GAC. But the assemblies trying to refer this assembly was of another version. Simply GACd the newer version of the assembly - Exception.dll in the GAC and it worked :-)

got subsonic compile error

I use visual studio 2010 and tried to use subsonic and i am getting the following error.
Error 2 Compiling transformation: Metadata file 'MySql.Data' could not be found D:\TradingTools\CODE\ConsoleApplication8\subsoniccomponents\Structs.tt 1 1 backtester
As you can see from the screenshot, i do have mysql.data in my references. i dunno how to fix this. Can you help fixing this problem.
http://postimage.org/image/s1es0mr79/
SubSonic uses the DbProviderFactory pattern.
The DbProviderFactory approach allows the creation of Connections/Commands/... without knowning the concrete type.
// without factory
var con = new MySqlConnection();
var cmd = new MySqlCommand();
// with factory
var factory = DbProviderFactories.GetFactory("MySql.Data.MySqlClient");
var con = factory.CreateConnection();
var cmd = factory.CreateCommand();
which is a way more generic approach.
However, in order for this to work, you have to install MySql.Data (the msi-Package) which makes some entries in the machine.config file.
That said,
I also prefer my build environment not to rely on installed software, which makes it a lot easier to switch to a new machine without installing multiple dependencies.
But this requires a little bit work:
Modify your app.config/web.config file and place this somewhere between <configuration> and </configuration>
<system.data>
<DbProviderFactories>
<remove invariant="MySql.Data.MySqlClient"/>
<add name="MySQL Data Provider" invariant="MySql.Data.MySqlClient"
description=".Net Framework Data Provider for MySQL" type="MySql.Data.MySqlClient.MySqlClientFactory, MySql.Data, Version=6.4.3.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d" />
</DbProviderFactories>
</system.data>
I just copied and pasted the snippet from
%windir%\Microsoft.NET\Framework\<version>\Config
after installing the MSI.
If your solution has multiple projects, you have to do this for the main project (so subsonic can find your provider at runtime) and in your DAL project (so subsonic can find your provider during code generation).
If you use another MySQL Version you can change that.
The second thing you have to do is to tell the templates where to find the MySql.Data.dll (if it is not in the GAC).
You can do this by editing the MySQL.ttinclude file (look at the assembly directive)
<## include file="Settings.ttinclude" #>
<## assembly name="$(SolutionDir)\Dependencies\MySql.Data.dll" #>
<## import namespace="MySql.Data.MySqlClient" #>
<#+
With these changes my solution runs find and template generation also works find on a clean install without any MySql Components installed.

fatal error C1084: Cannot read type library file: 'Smegui.tlb': Error loading type library/DLL

I am trying to build an old version of an application which consists of VC++ projects that were written in Visual Studio 2003.
My OS is Windows 7 Enterprise (64-bit).
When I try and build the solution I get the following errors:
error C4772: #import referenced a type from a missing type library; '__missing_type__' used as a placeholder
fatal error C1084: Cannot read type library file: 'Smegui.tlb': Error loading type library/DLL.
They both complain about the following import statement:
#import "Smegui.tlb" no_implementation
This is not a case of the file path being incorrect as renaming the Smegui.tlb file causes the compiler to throw another error saying it cannot find the library.
Smegui is from another application that this one depends on. I thought perhaps I was missing a dll but there is no such thing as Smegui.dll.
All I know about .tlb files is that they are a type library and you can create them from an assembly using tlbexp.exe or regasm.exe (the later also registers the assembly with COM)
There is also an Apache Ant build script which uses a custom task to invoke devenv.com to build the projects. This is the same script that the build server originally used to build the application. It gives me the same errors when I try and run it.
The strangest thing about this is that I knew it ought to work seeing as it is all freshly checked out from subversion. I tried many different combinations of admin vs user elevation, VS vs Ant build, cleaning, release.
I have got it to build successfully about 5 times but the build seems to be non-deterministic.
If anyone can shed some light on how this tlb stuff even works or what this error might mean I would greatly appreciate it.
I found a far more reliable solution: open the tlb with oleview.exe and then close it.
Not sure what this actually does but it works every time.
I think oleview is actually one of the samples included with Visual Studio but I haven't had the time to debug it and see what it is doing.
I ran into this error because one type library was trying to load a dependent type library, which it could not find. Even though the dependent type library was in the same directory, and even though that directory was in the searchable path, the compiler would error loading the first type library, but not mention the dependent type library in the error.
To find the pseudo-missing type library, I ran Process Monitor (procman64.exe) during the compile. This showed that after the reported type library had successfully loaded, a dependent type library could not be found. It even showed all of the places that it was looking for the dependent type library, none of which were where it should have been looking (e.g.: ).
The fix was to add a <PreBuildEvent> to the project to copy the dependent .tlb file to one of the directories that was actually being searched.
<PreBuildEvent>
<Command>copy /Y ..\Lib\Interop\CWSpeechRecLib.tlb .\</Command>
</PreBuildEvent>
http://msdn.microsoft.com/en-us/library/sce74ah7%28VS.71%29.aspx
smegui.tlb is referencing some other tlb that the compiler can't find. If you have the .idl for smegui you might be able to figure out what the other is. I suspect the missing tlb is something that original build machine had registered but that your machine doesn't have registered.
A type library is a binary description of a set of interfaces, coclasses and enums. They're usually generated for COM components, in the case of tlbexp and regasm the tlb is created from the assembly metadata. For native COM components they are usually generated from an idl (Interface Description Language) file by the midl tool.
Edit:
I just noticed you're on x64 Windows. Are you building the project with a new version of Visual Studio? If so, are you targeting x86 or x64? If the latter, it may simply be a 32bit component that the compiler can't find (or less likely, a x64 component the x86 compiler can't find if you are targeting x86), for WOW64 the registry is virtualized for x86 vs. x64 applications.
Well I finally found out why I managed to get it to build sometimes and not others... sort of.
So long as I ran the build script with elevated administrator permissions and let that get as far as it could until that error occurred, then run the build script again as a protected administrator succeeded. Those steps must be done in that exact order with no other steps in between. If I try build in Visual Studio it does not work (although I did get it to succeed once). Probably some kind of virtualisation issue although it still doesn't quite make sense.
Well I don't need help on this any more and I know it's probably impossible to fully answer this question without knowing exactly what the build is doing. However if anyone does have any more thoughts I would happily receive them.
Cheers,
Steiny

Resources