I have installed the ASP.NET MVC 2 RC and opened the default "example project", but get the following error:
Parser Error Message: The type
'System.Web.Mvc.ViewMasterPage' is
ambiguous: it could come from assembly
'C:\WINDOWS\assembly\GAC_MSIL\System.Web.Mvc\2.0.0.0__31bf3856ad364e35\System.Web.Mvc.dll' or from assembly 'C:\Documents and
Settings\sfent\My Documents\Visual
Studio
2008\Projects\MvcApplication1\MvcApplication1\bin\System.Web.Mvc.DLL'.
Please specify the assembly explicitly
in the type name.
This appears to be a conflict between the GAC dll and the dll created and placed in the bin directory (which I thought was supposed to be used in preference to the GAC version)
I have Googled this issue and have found similar problems, but relating to incorrect namespacing. This is the un-altered example application that comes bundled with the MVC framework.
I have also tried removing the framework entirely and re-installing the RC, but to no avail.
All suggestions appreciated.
I got this error, and in my case it was resolved quite easily.
I had made a new Master Page in my Views folder, but unnoticed by me, it came with code behind and designer, which of course you don't want with MVC2. It all built, but gave me that "Parser Error Message: The type 'System.Web.Mvc.ViewMasterPage' is ambiguous:..." error when I ran it.
To fix it, I removed the code-behind and designer files for my new Master page, and the error went away.
the problem might be that the Reference in your Project is still pointing to the old Version of the dll (v1.0). Delete the reference and add a new one to version (v2.0).
You find that hint as well in the release notes of MVC2 RC:
"Open the project using Visual Studio, and in Solution Explorer, expand the References node. Delete the reference to System.Web.Mvc (which points to the version 1.0 assembly). Add a reference to System.Web.Mvc (v2.0.0.0)."
Cheers,
Damrod
Does your project reference both v1 and v2 of the framework? Also, why not delete the matching dll that's been copied locally?
Related
"Type 'HR.Database' is not defined'
I get that error for several classes that are stored in the App_Code folder in the Error List panel when building my project.
It is a class I wrote with namespace HR
How can I reference it or alter the project to recognize those classes and remove the error?
I thought I should reference it but when trying to add a reference there are no items in the list of projects. Also, they are .vb files and not a .dll
I wasted the better part of a working day on this problem before figuring it out...
When you add files to App_Code, Visual Studio sets the "Build Action" property to "Content", instead of "Compile" which it does for all other classes. So your classes don't get compiled, and then VS complains that it can't find them. Presumably this is VS' way of saying that App_Code is not where you should put your app code, reasonable as it may appear.
The solution is to right-click on each file and reset "build action" to "compile". This also has to be done whenever you add files. Or you could submit to VS and put your source somwhere else.
< /frustration>
Since it's late and over 3 years old. I came across a similar issue. The solution above is perfect.
With newer VS IDE versions, go to App_Code file's properties and update the Build Action to 'Compile' if it's set as 'Content'. Using App_Code folder may be outdated in newer VS versions but some older developers still use the folder.
Replace vbproj and vbproj.user with your backup
My issue wasn't the App_Code folder in particular, but I was getting "not defined" errors in my Errors List until I double-clicked to open the file, then references would resolve and that error would disappear without me doing anything more, but when I tried to rebuild, all these errors would appear again.
The only real clue I had was that they were all related to the same project and when I dug through my Output window, I could see there was a conflict on the .Net framework versions. Once I resolved the version difference, the errors disappeared.
I was getting this issue for a slightly silly reason, but it might help for others to learn from my pain. :D
I was making the changes to the code in a tab of my test program, but that tab was for a VB file in a DLL I was using. Since those changes weren't being made/compiled in the DLL, it wouldn't find the class no matter how hard I tried until I opened the DLL project, made the changes there and rebuilt the DLL.
I had the same issue in Visual Studio 2019 but the .vb file already had "Compile" in properties > build action
I had tried rebuild, clean, deleting the file.
If I copied an existing class into this folder it would also not be recognised
Closing visual studio and restarting it fixed the issue, so there's a bug in VS where it doesn't compile files in a new folder until VS is restarted
Like many others I am getting the "Could not load file or assembly ... .dll". This problem happens when I try to compile as there is then a single error. I have tried adding a reference to System.Data.Entity and rebuilding, as well as also trying various things out from this stackoverflow answered question:
Could not load file or assembly 'System.Net.Http, Version=2.0.0.0 in MVC4 Web API
I have tried the "Copy Local = True" under properties under References for the particular .dll (It was already set to True), as well as "Always Copy" the .dll in question which is in the bin folder.
I have also tried to find the "runtime" code in the Web.Config file, there however is none in either that or the sub-files (web.debug.config and web.release.config). I thought that perhaps I could modify the version. There are about 10 other .dll references which seem to be working. I also did get the compilation and part of the first page to run the first time, but not after that. Error information is at the bottom.
I have read that there seems to be a problem with NuGet but I don't know if I should remove it as I don't know what it does and might find it useful later. I am using Visual Web Developer Express 2012.
'Could not load file or assembly 'ComponentArt.Web.UI, Version=2008.1.1202.3, Culture=neutral, PublicKeyToken=null' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)' C:\Users\Brian\Desktop
I think you might be using the ComponentArt dll that depends on WebForms in MVC4 project. You need to create a WebForms project and then you will be able to add that DLL.
I have some user controls in the project kept under a folder UserControls.
I'm using one of the user control from that folder in my master page and one on Default.aspx. The default.aspx uses that master file.
The problem is that everything was working fine until something happened and it seems user control is not getting compiled. The user control calls a method from Business Logic which was parameterless before (when everything was working fine) but when I changed it to accept parameters and of course its calls too, it started giving the error. It is still searching for that parameterless method..!! :(
I did tried manually deleting the DLLs, deleting the user controls and again creating them. But nothing worked.
Anyone has any idea what I did wrong or what am I missing??
Try checking the build configuration manager (Visual Studio 2008 -> Build -> Build Configuration Manager). I ran into a similar issue and it turned out that one of the projects I was referencing was not marked to actually build (there is a check box that should be checked to build the assembly). Try changing the assembly version number of the assembly that is creating the issue, rebuild, then check that the version number of that assembly is correct.
I came across this problem and it was due to the fact an older version of my bin-deployed assembly existed in the GAC. Unfortunately there is no way to force DLLs to load from the bin directory if the GAC version has the same version number. See here: Dll in both the bin and the gac, which one gets used?
This one’s a head scratcher. Here’s the deal.
While deploying a beta copy of an ASP.NET application built with Delphi 2007 for .NET to a test server I encountered an odd problem. The application was unable to start because it could not load the correct version of an ADO.NET data provider that I was using.
Only by including a version of the old assembly in the bin directory would the application run. However, I don’t want to be tied to this older .NET data provider, so I am determined to find a solution to this problem.
I originally compiled the project with the .net data provider assembly used as Copy Local, which should have caused Delphi to use a copy of that version of the assembly that I selected when I added it to the References folder in the Project Manager. The actual assembly that I selected was version 9.10.2.0, and that is the version of the assembly that appears in the bin directory, along with the application. However, at runtime the application was trying to bind to an earlier version of the same assembly, 9.0.2.7.
(Actually, this problem occurs whether or not I use the GAC version of Copy Local, so I don’t think this is the issue.)
While investigating this problem I created a new project, and added a reference to the 9.10.2.0 assembly. Still, both the .NET 2.0 Configuration Utility and Reflector showed that the application compiled with a reference to the 9.0.2.7 assembly.
Inspecting the GAC I saw that both 9.0.2.7 and 9.10.2.0 versions were registered. Attempting to remove the 9.0.2.7 version fails, since that version of the provider was still referencing the assembly in the GAC.
I went into the registry and manually removed all references to the 9.0.2.7 provider. I then was able to delete it from the GAC. This didn’t change anything. Removing the assembly from an existing application and then adding the 9.10.2.0 version back, then compiling, still resulted in the wrong assembly information being inserted into the application. As before, creating a new application that referenced the 9.10.2.0 assembly didn’t work, as a reference to 9.0.2.7 was still being inserted into the executable.
I’ve checked the Delphi library search path. I also removed every instance of the old assembly files from the machine altogether (including from the ASP.NET Temporary Files directory). I still got the problem. I tried using Issam Ali’s AppManifest utility to manually adjust the manifest, but apparently it does not support ASP.NET applications in Delphi 2007 for .NET.
So, the GAC no longer contains references to 9.0.2.7, there are no references to it in the registry, there are no paths to the old provider directory in the project or Delphi options dialogs, the old provider assembly is not on the file system, and 9.0.2.7 does not appear in any of the project files. Nor does it appear in web.config, machine.config, or any other file I checked. Nonetheless, Delphi insists on using this version of the assembly anytime I reference the 9.10.2.0 version of the assembly. (Yes, I restarted Delphi, and also restarted the Virtual Machine in which this development was being performed.)
Even after uninstalling the 9.10.2.0 data provider (the older one was already uninstalled), and reinstalling it, adding the data provider reference to an application results in the runtime application attempting to load the old provider (even though no reference to the old provider apparently remains in the system).
I’ve tried other solutions (which are worth mentioning here), but none worked. Anybody seen this? I am going to continue working on this problem, but I’d love to hear suggestions. I just can’t get Delphi to stop inserting the old assembly information into the project.
For grins I’m including the error log from the failure. This log essentially duplicates the information I get from the fusion log. This log is from one of the simple apps I created after removing the 9.0.2.7 assembly from the GAC. Notice that it’s looking for the old version of the provider from the outset.
Assembly manager loaded from: c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Running under executable c:\windows\microsoft.net\framework\v2.0.50727\aspnet_wp.exe
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: User = TRAINING8A\ASPNET
LOG: DisplayName = Advantage.Data.Provider, Version=9.0.2.7, Culture=neutral, PublicKeyToken=e33137c86a38dc06
(Fully-specified)
LOG: Appbase = file:///C:/Inetpub/wwwroot/TestAdsVer2/
LOG: Initial PrivatePath = C:\Inetpub\wwwroot\TestAdsVer2\bin
Calling assembly : TestAdsVer2, Version=1.0.3572.17384, Culture=neutral, PublicKeyToken=null.
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Inetpub\wwwroot\TestAdsVer2\web.config
LOG: Using host configuration file: c:\windows\microsoft.net\framework\v2.0.50727\aspnet.config
LOG: Using machine configuration file from c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Post-policy reference: Advantage.Data.Provider, Version=9.0.2.7, Culture=neutral, PublicKeyToken=e33137c86a38dc06
LOG: Attempting download of new URL file:///c:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/Temporary ASP.NET Files/testadsver2/07545aea/3d068a5/Advantage.Data.Provider.DLL.
LOG: Attempting download of new URL file:///c:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/Temporary ASP.NET Files/testadsver2/07545aea/3d068a5/Advantage.Data.Provider/Advantage.Data.Provider.DLL.
LOG: Attempting download of new URL file:///C:/Inetpub/wwwroot/TestAdsVer2/bin/Advantage.Data.Provider.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Minor Version
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated
This has gone on so long that the comments that I added to LanceSC's answer are no longer showing. But I do thing this is an interesting item that I want to address.
Here's my last two comments to LanceSC
The installation that exhibited this behavior is in a VM that is no longer functioning. Another developer I know experienced this same problem. The solution was to abandon the installation. I feel that something in the installer of the particular version of this .NET data provider left some strange artifact that produced the problem. It does not happen with any other build of this data provider. I am no longer pursuing an answer to this question.
Spoke too soon. A colleague of mine, today (March 5, 2010), encountered this same error, with a slightly earlier version of this same .NET data provider (9.0.2.1). He is now in the same position I was. He cannot run his application with any version of the data provider, save the old one. That assembly was being used as a local copy, and the old version is not in the gac. Using his machine, we ran the run MSBuild with the verbose option. The build worked fine with no errors. Nonetheless, the compile application failed to run, having failed to find the old version of the provider.
Summary
My colleague resigned himself to reinstalling Delphi 2007 (fortunately, he was working in a VM, and had a second VM with Delphi 2007 in which the offending .NET data provider had never been installed. This was also my tactic.
At this point, I have concluded that this problem is not solvable. Nonetheless, I am leaving this question open for another week or so. If no feasible solution is proposed in the next few weeks, I will close this question.
In the meantime, I have asked my colleague to preserve the VM with the misbehaving provider, in order to test any solution or investigation that is proposed.
Delphi 2007 uses MSBuild to perform the actual builds; however, the code in their product that syncs changes between the IDE and MSBuild is very brittle. My suspicion is that the build files are out of sync with the IDE. An easy way to update them is as follow:
Open your registry editor go to
HKEY_LOCAL_MACHINE\SOFTWARE\Borland\BDS\5.0\Globals
Change the value of ForceEnvOptionsUpdate to 1.
Open the RAD Studio IDE.
In order to confirm my suspicion you need to locate the files that Delphi.NET feeds to MSBuild. They are located somewhere under the current user's profile. You may also want to look at options in the Delphi help to have it do a verbose MSBuild output.
Have you tried grep'ing the Delphi and .NET framework directories for 9.0.2.7 to see if it is in a config file somewhere?
Something like:
grep -d 9\.0\.2\.7 *.xml
Other places you might search:
search the project files for 9.0.2.7
registry search for 9.0.2.7, and a search using the public token
If this app uses the BDP you might also search the BDP config files
I ran into something very much like this, and it drove me absolutely up the wall for days. I had a reference to Oracle.DataAccess.dll that was resolutely stuck pointing at an old version, regardless of what was in the GAC, in the search path, etc. No amount of restarts of modifications to the .dproj files would ever work.
What I eventually found was that the offending piece that was holding on to the old reference was the generated Oracle.DataAccess.dcpil in the C:\Users\Public\documents\rad studio\5.0\dcp directory.
It was over a year old - whatever the case was, Delphi did not want to write over it.
Once I deleted it, Delphi merrily created another one, and sure enough, it now points to the assembly I want it to.
Ugh, frustrating!
I get this error in my ASP.NET 3.5 website:
Error 3 Cannot update project reference 'Services'. Source project not available.
How can I track down any reference to this assembly so I can then delete it? It must be called from somewhere. I no longer have an assembly in my project with this name.
Thanks
Check your references: in your Reference Paths Dialog Box (Visual Basic) or the Reference Paths Page, Project Designer (C#, J#).
See this link in MSDN for details: How to: Add or Remove References in Visual Studio
I didn't have much luck with the previous answer for web projects, so I thought I'd offer another way. Web project references are kept (non-intuitively) in the solution file, and with care you can edit this file to remove the reference.
Close the solution if you have it open, then open solution file in a text editor.
Search for name of the project that failed to load. This should bring you to the configuration section for your web project.
Inside that should be a line beginning with "ProjectReferences", with a semicolon-separated list of projects.
If you CAREFULLY remove the offending project, which includes a GUID and the assembly name for the project, then save the solution file, you should be good to go.
Be sure to allow yourself a backup strategy in case something goes wrong.
I'm using Visual Studio 2008; I don't know if it works exactly the same way in other versions.