I'm building an ASP.net application using Visual Studio Web Developer 2010 Express and have followed the Nerd Dinner tutorial for a large part. The problem is that when I try to build, it is constantly giving me a build error saying:
Error 43 Could not load file or
assembly 'System.Data.Entity,
Culture=neutral,
PublicKeyToken=31bf3856ad364e35' or
one of its dependencies. The system
cannot find the file specified.
This error is coming from the file "ASPNETCOMPILER" apparently. Some things that I have already checked are:
There is a reference to System.Data.Entity in the project references already.
I have .Net 4.0 installed on the system.
Any ideas on what could be wrong?
Try copying the System.Data.Entity.dll into your bin folder, or target your system to use .NET 2.0, as that should copy it over automatically.
Posting back for community goodness, the first comment in this thread by "DonSleza4e" seemed to solve my problem.
Related
I am working on a system which scaffolds a migration from inside our code using ToolingFacade.
The system worked fine in entity framework 4.3.1. After the Upgrade to 5.0 I see that the correct entity framework version is loaded when starting out tool, however when I call the scaffold method I get the following exception:
Could not load type 'System.Data.Entity.Migrations.Design.ToolingFacade+ScaffoldRunner'
from assembly 'EntityFramework, Version=4.1.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089'.
Does anyone know why calling a method in entity framework 5.0 requires an older version dll?
I ran into this issue recently when using EF6. Visual Studio required me to re-install EntityFramework via the Package Manage console to get things working again. Note that when I did so, the console output suggested that it had no idea that EF was installed before; somehow the association had been lost. Perhaps this is why the tooling assembly or assemblies weren't being loaded.
In any case, reinstalling the package via the console (and a restart of Visual Studio) solved the problem for me.
I installed Crystal Reports for VS 2010 from http://www.sdn.sap.com
When I create new Crystal Report in the CrystalReport.cs class there are few errors:
The type or namespace name 'Engine' does not exist in the namespace
'CrystalDecisions.CrystalReports' (are you missing an assembly
reference?)
I manually browsed the CrystalDecisions.CrystalReports.Engine.dll and added it to the References but still gives me the error
The same error gives me for CrystalDecisions.ReportSource
The same error gives me for CrystalDecisions.Shared
Also the CrystalDecisions.CrystalReports.Engine doesn't exist when I go to Add Reference .NET tab ..
For all those who has still this problem:
Somehow i figured out that there are problems with .NET 4, with .NET 4.5 & VS2012 they just work fine.
I haven't tried Ally's solution but that maybe is the right answer to my problems, but whatever i switched to vs2012 & 4.5 so they work just fine.
Thanks
You Must Change Version Of .Net In Project Properties. In Tab Application, Change Target framework To .Net Framework 4. I exactly had problem. In fact, initial .Net Framework When I created Project was .Net Framework 4 Client Profile. As I told, I changed to .Net framework 4.
Problem solved perfectly.
I am using VS2010 with SP1 (also have VS2012 installed on the same machine). Moles 1.0
The project is using .NET 4
I added moles assembly to system.dll and get the following error on compile
Error 46 The type or namespace name 'IReadOnlyList' does not exist in the namespace 'System.Collections.Generic' (are you missing an assembly reference?) [C:\Test\obj\Debug\Moles\s\m.g.csproj] C:\Test\m.g.cs Test
IReadOnlyList .NET 4.5 as far as I know.
Anyone else got this issue?
Updated Solution
I was able to get Pex to run in VS 2010 with .Net Framework 4.5 installed. Maybe others have explained that this is the solution but my issue (being new to Moles and Pex) is that many of the explanations were vague. Thanks to the author of these posts because they got me headed in the right direction:
http://feherzsolt.wordpress.com/2013/02/13/moles-and-net-4-5/
http://www.daedtech.com/using-moles-with-the-system-assembly
So the solution is to create a new .moles file (System.moles) in the test project at the same level that Pex created the yourAssemblyUnderTest.moles file and add the following to the file.
<Moles xmlns="http://schemas.microsoft.com/moles/2010/">
<Assembly Name="System" ReflectionOnly="true" />
</Moles>
You may have to clean (or manually delete the obj folder contents) and rebuild but this solution worked for me. I also noticed that the first build would report build errors, but the errors would go away on subsequent builds.
Alternative Solution
I know this isn't THE solution but it is a (poor) workaround that allows Pex to run...plus this was too long for a comment. If anyone knows how to get PEX to run on a machine with the 4.5 .Net Framework PLEASE respond.
This was my scenario. I have a machine with the .Net Framework 4.5 and I have Visual Studio 2010 and 2012 installed. I installed Pex (en_visual_studio_2010_pex_0.94.51023.0_power_tools_x64_598803.exe) and could run Pex in a VS 2010 project that was targeting .Net Framework 4.0. I could run Pex and it identified issues...but once I promoted issues to Unit Tests the unit test project wouldn't compile because of the following build error
The type or namespace name 'IReadOnlyList' does not exist in the namespace 'System.Collections.Generic' (are you missing an assembly reference?)
After much searching, and reading that Pex or Moles was replacing 4.5 .Net Framework assemblies with 4.0 versions I decided to uninstall 4.5, install 4.0, and give it a try. Running on 4.0 works just fine and I didn't need to define Mole type filters to get it to work. Then I tried tried to upgrade to the 4.5 Framework again...but sadly I end up right back where I started with the IReadOnlyList namespace issue.
We are using enterprise library 4.1 and smart client software factory 2008 to our application.
how we can upgrade enterprise library 5.0 and SCSF 2010 to our application.presently we are using visual studio 2008.
To upgrade what are the thing needs to be taken care.
Early help would be appreciated.
In terms of Enterprise Library, the best case scenario would be to replace the 4.1 assembly references with 5.0 assembly references and change the configuration (to use 5.0 references instead of 4.1 references). However, you could also hit some issues.
You should read the Microsoft Enterprise Library 5.0 Migration Guide for a full description. The Breaking Changes document could also help you determine if you may run in to migration issues.
For the Smart Client Software Factory the approach appears the same: change the references and configuration to use the new dlls. The Web Client Software Factory 2010 Documentation download has a section on Migrating to Visual Studio 2010.
Install the 5.0 package.
remove all the previous refreneces and add the newer ones generated.
You can refer the dlls by copying it to some folders or directly from the location where you have installed (C:\programfiles\Microsoftenterpriselibrary5.0)
I faced the below issues while migrating
Configuration errors in web.config files - some of my references in the web.config files were refering to the older version(2.0.0.0)(i upgraded from 2.0 to 5.0) and the publictokenkey="null"
so i pushed all the dlls to the gac and added the publicktokenkey from the c:\windows\assembly. which solved the issue
And another issue was regarding the microsoft.practices.enterpriselibrary.caching.cryptography- it was displaying soem weird error.- solution-the bin folder was having the old dlls and when tried to
clean the solution the dll reference was still there. SO i deleted all those from the folder and rebuild again.
IT was initially having the logicacmg.enterpriselibraryextensions.logging which caused some issues- i used the microsoft.practices.enterpriselibrary.logging.configuration.rollingflatfiletracelistenerdata which could solve the issue.
Hope some one might get some inputs with this post
All,
I'm currently in the process of attempting to create a repeatable process for the upgrade of a TFS 2008 installation to new hardware in what Microsoft call a migration upgrade, but am experiencing issues when building the VS 2008 projects on the new hardware.
Our TFS 2008 installation consists of two machines; one which houses the SQL databases and Application Tier, and the other which acts as a dedicated Build Server.
The new hardware for our TFS 2010 installation consists of two machines; one which houses the SQL databases, Application Tier, SharePoint and the Reporting Services.
So far, I have managed to successfully repeat the backup of the necessary TFS databases from the original server to the new server and restore them, followed by the 'tfsconfig import' command to successfully import and upgrade the databases to a Team Project Collection. The Team Project Collection appears correctly, and it is immediately usable. All security settings, shelvesets, workspaces etc. are intact.
Our issues start when we begin trying to build solutions. We are initially trying to build these solutions without upgrading them to the VS 2010 format, nor modifying the target Framework of any of the projects.
We get the following errors when various projects build:
< filename>.resx(x,y): error RG0000: Could not find a type for a name. The type name was 'System.Collections.Generic.List`1[[< class>, < assemnbly>, Version=a.b.c.d, Culture=neutral, PublicKeyToken=9557797252b44220]], mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. Line x, position y. [< projectfilename>]
ResGen : error RG0000: Could not load referenced assembly "< filename>.dll". Caught a FileNotFoundException saying "Could not load file or assembly '< filename>.dll' or one of its dependencies. The system cannot find the file specified.". [< projectfilename>]
Various 'ambiguous' MSBuild target references when compiling workflow-related projects:
C:\Program Files (x86)\MSBuild\Microsoft\Windows Workflow Foundation\v3.5\Workflow.VisualBasic.Targets (153): 'GeneratedCodeAttribute' is ambiguous in the namespace 'System.CodeDom.Compiler'.
There are various suggestions about how to eliminate these issues, including modifying the 32-bit support flag on ResGen, or forcing the use of the 64-bit ResGen, and upgrading projects to VS 2010 format and changing them to target Framework 4.
Issue 1. can be fixed by changing the offending projects to target Framework 4, however this particular project cannot be upgraded yet due to compatibility issues, and I have not yet found a solution for issues 2. & 3.
We have upwards of 20 Team Projects, with multiple branches in each, and would therefore (due to the amount of work involved) like to avoid manually changing all projects/solutions (especially as some products cannot be upgraded to Framework 4 yet for compatibility reasons, and building Framework 3.5 targeted projects in Framework 4 MSBuild does not appear to be as compatible as Microsoft would have us believe).
If anybody has any ideas which may prove helpful, then please let me know.
Cheers,
Antony
EDIT:
Issue 1 has been seen by other people, and relates to resource files referencing generic lists of a custom type. As it turns out, these were superfluous in our project, so I simply removed them, and that build issue was history.
Issue 2 seems to have dissappeared all by itself, possibly as a result of fixing issue 1.
Issue 3 relates to building VS2008 Workflow projects in MSBuild 4, when they target Framework 3.5. Microsoft, in their infinite wisdom, have apparently chosen to not address this issue (Link to Connect site), and there are several ideas to fix it (referencing specific versions of the Framework, changing the build workflow to use MSBuild 3.5), none of which work.
So our upgrade to 2010 is on hold it would seem, until either the products for which we build the 3.5 workflows (CRM 4.0 and SharePoint 2007/2010) support Framework 4, or until Microsoft fix the issue.
EDIT:
Microsoft have admitted that there is an issue, and have released the following information relating to the above KB number: http://support.microsoft.com/kb/2023579
As stated in my commented addition on my original post, this issue relating to the workflows not building is indeed resolved by a patch for the Microsot .Net Framework 4 Extended, which is outlined in KB2023579, which has not yet been made public (at the time of this post).
This solution was provided by Microsoft through a support call, and as such I am bound by the terms and conditions of that call, which prevent me from distributing a link to the patch until the official KB article is made available, at which point I will post the link. Sorry.
Hotfix that worked for us: http://support.microsoft.com/kb/2249629