[EDIT: It is a memory issue. The memory on my computer goes from 42% used to 91% in a few seconds just before this error. The error message about the compiler supporting up to 2012 is just a red-herring. That message is always output from the compiler. ]
I just converted a visual basic application from VS2005 to VS2017.
I get this error when I try to start it:
Server Error in '/' Application.
Compilation Error Description: An error occurred during the
compilation of a resource required to service this request. Please
review the following specific error details and modify your source
code appropriately.
Compiler Error Message: The compiler failed with error code
-2147024888.
Show Detailed Compiler Output:
C:\Program Files (x86)\IIS Express> Microsoft (R) Visual Basic
Compiler version 14.7.2556 for Visual Basic 2012 Copyright (c)
Microsoft Corporation. All rights reserved.
This compiler is provided as part of the Microsoft (R) .NET Framework,
but only supports language versions up to Visual Basic 2012, which is
no longer the latest version. For compilers that support newer
versions of the Visual Basic programming language, see
http://go.microsoft.com/fwlink/?LinkID=533241
Version Information: Microsoft .NET Framework Version:4.0.30319;
ASP.NET Version:4.7.2556.0
Here is what I tried:
Followed the fwlink and it actually redirects to github that appears to be some open source version of the compiler that will support my old code. I have no interest in doing that.
Reading the answers to this question: Compilation Error when change .Net framework from 4.5.2 to 4.5 in VS 2015 Community edition
I tried to follow the instructions, but those instructions seem to be for a MVC project and my project is a Web project [Note: I am new to Visual Studio so I probably have that wrong] but what I am sure of is:
a. I don't have a project file.
b. I see a globe icon on my project.
c. When I right click on the project (globe icon thing in solution explorer) I do NOT get a Properties menu item.
So, how do I get past this error where my preference is to update my code to current techniques rather than patch together libraries to get it to run.
[EDIT] This problem just occurred on a different project/solution that actually does have a project file. This was converted from VS2005 to VS2017 a couple of months ago and has been working fine. I suspect some configuration change in VS2017 that is affecting all solutions.
[EDIT] The comment about out of memory seems promising except it fails in exactly same spot every time. A reboot did not help. This is an i7 with 16GB and 500GB SSD with 400GB free. If it is running out of memory it might be some config in VS that artificially limits memory of that particular process. I am going to deeper into this lead.
[EDIT] I have IIS Express 10.0.1740 installed.
[EDIT] I tried installing the Roslyn compiler using nuget. The error message did not change, but it could be I need to do some additional config to get it to be the compiler used for this solution/project. The problem is happening while the application is running so presumably iisexpress is doing the compiling.
[EDIT] This is also happening on a different project that does have a .vbproj file. I suspect some update that is causing the issue.
[EDIT] I am now testing in a project that has a .vbproj file. To change target framework I do Project -> XXX Properties -> Application -> Target Framework 4.6.1. The problem still happens. Note the warning in the message that it may require additional hand edits. I did not know what to edit, so I did not make other changes.
[EDIT] Note that the compiler version is 14.7.2556 And it is complaining about being for VB2012. This seems to conflict with https://en.wikipedia.org/wiki/Visual_Basic_.NET that says that vb compiler 14.0 came out in 2015.
[EDIT] I did not have a section in web.config, so there is nothing to remove.
[EDIT] I do not have a compilerOptions= tag in web.config, so there is nothing to change.
With a an i7 with 16GB and 500GB SSD with 400GB free I doubt this is a memory issue, I'm guessing the ERROR_NOT_ENOUGH_MEMORY is a symptom of the root cause:
This compiler is provided as part of the Microsoft (R) .NET Framework, but only supports language versions up to Visual Basic 2012,
In other words the compiler only works with projects upto 2012, so lets just change what commpiler we use by targeting an up-to-date version of the .Net Framework (right click on Project > Property Pages):
You also can safely remove the CodeDom that's used for Dynamic Compilation in the web.config:
<system.codedom>
<compilers>
<compiler language="c#;cs;csharp" extension=".cs"
type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
warningLevel="4" compilerOptions="/langversion:6 /nowarn:1659;1699;1701"/>
<compiler language="vb;vbs;visualbasic;vbscript" extension=".vb"
type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.VBCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
warningLevel="4" compilerOptions="/langversion:14 /nowarn:41008 /define:_MYTYPE=\"Web\" /optionInfer+"/>
</compilers>
</system.codedom>
Or you could change the compilerOptions="/langversion:6 compiler version.
If this doesn't work, make a cut down https://stackoverflow.com/help/mcve in VS2005 that we can reproduce the problem with and upload the solution somewhere we can download it.
#jmcilhinney you were on the right track. I worked with #Michael Potter and found that, on the local machine, IIS is having trouble doing the just-in-time compile a "Website" requires. I've no deeper knowledge than that (and not sure I want any) but the issue was fixed (in this case) by switching to HTML pages (it is mostly a SPA site).
Had we more code-behind than we do, I would simply switch to a "Web Application".
Related
I am installing a C# windows service that uses Geode onto a UAT Windows 2012 server. The referenced dll (like log4net, newtonsoft.json and QuickFix) are working except for Pivotal.Gemfire.dll
When I start the service I get System.IO.FileNotFoundException: Could not load file or assembly 'Pivotal.Gemfire.dll' or one of its dependencies. The specified module could not be found. File name: 'Pivotal.Gemfire.dll'
Now Gacutil doesn't come with Win Server 2012. I've tried installing Windows SDK and .Net SDK and not found a Gacutil executable. So I've tried to get in the dll into the GAC using powershell like this:
[System.Reflection.Assembly]::Load("System.EnterpriseServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")
$publish = New-Object System.EnterpriseServices.Internal.Publish
$publish.GacInstall("D:\Pivotal.Gemfire.dll")
I've tried regsvr32 Pivotal.Gemfire.dll in various flavours
I've tried compiling and running the GacInstall executable at https://github.com/apache/geode-native/tree/develop/executables/GacInstall. It says Installation completed successfully. but when I try to run the service, or try powershell:
([system.reflection.assembly]::loadfile("D:\Pivotal.Gemfire.dll")).FullName
I get the same error.
I've tried a private assembly using runtime assembly binding
<runtime>
<assemblyBinding
xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Apache.Geode" publicKeyToken="null" culture="neutral" />
<codeBase version="9.1.1-build.2" href="file://Pivotal.Gemfire.dll"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
and various flavours of name Pivotal.Gemfire, Apache.Geode.Client according to Implementing Shared Assembly but always the same error.
Any ideas? Thanks...
UPDATE: Make sure you have x86 and x64 bit C++ packages back to 2013 (for older versions of Geode Net client)
I downloaded the previous version of Geode, 9.0.7, called Gemstone.Gemfire.Cache.dll and got the same error, but that version included a Gemstone.Gemfire.Cache.xml in the same directory. If I took the xml file to my bin directory the error stopped and the service started properly.
So like this the problem is a redundant accompanying xml file to the dll. I fixed the issue by creating a new dummy xml file Pivotal.Gemfire.xml
<?xml version="1.0"?>
<doc>
</doc>
For me the marked answer did not work.
I had to download DependencyWalker which showed me why the Pivotal.Gemfire.dll was not working. One of missing DLLs was from:
Visual C++ Redistributable Packages for Visual Studio 2013
After installing 64x bit, application started to work.
This problem happened again with another install. The answer above using the xml file did not resolve it, it was resolved by downloading version 9.0.7 of the Native Client, Gemstone.Gemfire.Cache.dll and then running
.\gacutil /if C:\Gemstone.Gemfire.Cache.dll
which returned Assembly successfully added to the cache then removing the earlier version of the dll, but retaining the later version Pivotal.Gemfire.dll that I could not get into the GAC because of a strong name issue. This bizarre workaround of getting the earlier version of the dll into the GAC allows the GAC to find - and use - the later version...
This happened to me again with a Geode Native built locally, when it is run on a new Windows 10 install the dependency walker shows missing MSVCP140D.DLL VCRUNTIME140D.DLL and UCRTBASED.DLL as here
The D is related to having built the client in debug mode.
The problem is related to How can I install a Visual Studio C++ redistributable if it is missing? and the answer is either to get a release build of your dll, or to go to Visual Studio Installer, Modify, navigate to Individual components -> compilers, build tools, and runtimes, and check the MSVC v 140 VS 2015 C++ build tools
Yet another time this happened to me and I had to remove references and files to Apache Geode dll built as native client, then reference them all again.
I am using the setup from sqlite.org:
http://system.data.sqlite.org/downloads/1.0.94.0/sqlite-netFx451-setup-bundle-x64-2013-1.0.94.0.exe
Setups for 64-bit Windows (.NET Framework 4.5.1)
My application is set up to use framework 4.5.1.
"Prefer 32 bit" is not checked.
During Debug Mode, it runs flawlessly.
However, when I switch to Release Mode, I am getting this error:
"BindingFailure" detected at "D:\Dev\Projects\MyProject\AppNet\MyApp\MyApp\Release\MyApp.vshost.exe"" festgestellt.
The assembly "System.Data.SQLite" could not be loaded in AppDomain1 in the binding context of "Load":
System.BadImageFormatException: The file or assembly "System.Data.SQLite, Version=1.0.94.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139" or one of its dependencies was not found.
Can somebody tell me how I should do differently?
It seems that my question is a duplicate of
Could not load file or assembly 'System.Data.SQLite'
In this post, there was no real answer but just the suggestion to use x86.
However, I think that this is only a workaround, not a real solution, because the SQLITE binaries are clearly marked 32bit and 64 bit, and I have chose then correct assemblies.
Actually I already resolved this issue but still I'm not really happy with the way I resolved this issue.
I have VS2010 SP1 and I need SP1 to work with Azure SDK.
First of all installing Pex and Moles somehow created problems with System.XML.dll. It just disappeared from References in all projects. I had to explicitly find it and connect it to all solutions that used it.
Also, there was a bigger issue with Moles itself. TestProjects just weren't able to find
Microsoft.Moles.Framework.dll. And it generated all kinds of errors.
When I tried to add reference to Microsoft.Moles.Framework in "Add Refernce" dialog I got message: "Microsoft.Moles.Framework, Version=0.94.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" is incompatible with .NET Framework 4
Solution was to explicitly add reference to Microsoft.Moles.Framework.dll in C:\Program Files\Microsoft Moles\PublicAssembliesSilverlight. And after that all works fine so far.
I hope this info can be helpfull to someone.
I am having a strange problem since installing the latest version of ODAC, 11.2.0.2.1. I installed both the 32-bit and 64-bit versions because I develop applications for both architectures. My computer is Win 7 64-bit.
Since installing ODAC and referencing the new 64-bit version of ODP.NET, one of my web application projects in Visual Studio 2010 gives the following warning for all aspx pages and masterpages when I view them in Markup View.
ASP.NET runtime error: Could not load file or assembly 'Oracle.DataAccess' or one of its dependencies. An attempt was made to load a program with an incorrect format.
The warning is limited to Markup View. The web application builds and runs fine. I tried cleaning the VS Temporary ASP.NET Files, but that did not fix the issue. I removed all references to Oracle.DataAccess throughout my application, and then readded them to be sure that all the references were correct. The web app is compiled to 'Any CPU' but it uses the 64-bit Oracle.DataAccess. I created a new project, and referenced the same projects and dlls, and I do not get the warning, so it appears to be specific to this project file.
Any ideas why I would get the warning when in Markup View?
Expressly set the "Platform target" to "x86" or "x64" in the project properties --> Build tab.
Do NOT set it to "Any CPU." This is one of many common conditions which causes this driver of typical Oracle software quality to have a nervous breakdown.
Turns out the ODAC 11.2.0.2 xcopy installer doesn't correctly register all of the dlls (See bottom answer). As a result, Oracle.DataAccess.dll (64bit) was being copied into the BIN directory, and VS was trying to load it when in Markup View causing the warning. After manually registering the missing DLLs and rebooting, I am no longer having the problem.
Ideas you can check:
Check the Oracle.DataAccess reference in your Visual Studio project has the 'Specific Version' property set to 'False' (this is not the default).
Use the Fuslogvw.exe to determine what are the locations the .NET Framework is trying
I have a project that works great on my machine (and production servers).
It's a VS2010 project running C#3.5.
When letting my build server build the solution it can't resolve a couple of my third party dll's.
Error message:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets(1360,9):
warning MSB3268: The primary reference
"Third.Party.Assembly,
Version=50.11.2.0, Culture=neutral,
PublicKeyToken=0561a7c6dbd6f0ea,
processorArchitecture=MSIL" could not
be resolved because it has an indirect
dependency on the framework assembly
"Microsoft.VisualBasic.Compatibility,
Version=8.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a" which
could not be resolved in the currently
targeted framework.
".NETFramework,Version=v3.5". To
resolve this problem, either remove
the reference "Third.Party.Assembly,
Version=50.11.2.0, Culture=neutral,
PublicKeyToken=0561a7c6dbd6f0ea,
processorArchitecture=MSIL" or
retarget your application to a
framework version which contains
"Microsoft.VisualBasic.Compatibility,
Version=8.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a".
[d:\Builds\3\mySolution.sln]
Everything compiles and runs great on my machine, but the build server seem to struggle.
I think the Third.Party.Assembly is written in VB.net.
Since the assembly is third party I can't remove the reference to "Microsoft.VisualBasic.Compatibility" and since I don't get any warnings on my computer could it really be that I'm running v3.5?
Any suggestions?
/Jimmy
If you put your project on the build server manually will it run? Based on the error message, I would make sure you have the latest .net framework installed on the build server machine and give it another try. If that does not work try installing VS2010 on the build server just to get the builds running until you find out just exactly what assemblies you are missing.
So, I was having this issue also on a VS2005 project that we upconverted... The issue is that MS has never had a 64-bit version of the VisualStudio.Compatability DLL. Our issue was that we were targeting 'Any' CPU and building on a new W2008R2 server so it was using the 64-bit version of the .NET 4.0 Multi-targeting pack.
In the build properties under the 'Process' tab under the '3. Advanced' there is a 'MSBuild Platform'. Change that value to "X86" and it might work... assuming of course you aren't depending on any 64-bit libs...