When ever I start a blank WPF project in Visual Basic 2010 (SP1) I get the following error:
Type
'Microsoft.VisualBasic.CompilerServices.DesignerGenerated'
is not defined.
The error comes from the auto-generated code in MainWindow.g.i.vb - when I try to add a reference to Microsoft.VisualBasic, it says I can't because it will be added at runtime.
I search of the MSDN forums found nothing, a workaround on MS Connect was to install SP1 (which I have done).
Anyone else have this prob or know how to fix it?
I have got the same Problem and fix it with this:
(I have the German-Version of VS, so i do not know the correct description of the buttons.)
Advanced Compile->Change your framework and say OK. After this change is back. Then go to clean your project(find under build) and rebuild it new.
If VS when it breaks down later, you have the problem-again. The Downloads have only change my memory-space.
I had this problem and found it was due to adding a namespace of Microsoft.MapPoint (in fact any namespace starting "Microsoft" caused it). This was a class from a Microsoft article: http://msdn.microsoft.com/en-us/library/bb259689.aspx
Renaming the namespace to something without Microsoft in it fixed the problem.
Try to install the file from Microsoft
VBWP7SetupENU.msi
See the instructions and the required files in:
http://msdn.microsoft.com/en-us/library/ff402530(v=vs.92).aspx#BKMK_Installing
Good luck
Related
I am moving a solution with multiple projects to VS 2015. The base project builds just fine in VS 2013. But when I try to build in VS 2015 I get the error below.
C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.VisualBasic.Core.targets(56,5): error MSB6006: "vbc.exe" exited with code -2146232797.
Need help please
I talked with MS Tech Support. It's a confirmed bug in the VB compiler. They say it will be fixed in the next update.
In the mean time the work around is to install a Nuget package.
Please follow these instructions to install Nuget package.
Open the affected project in Visual Studio
Open the Package Manager Console (Tools -> NuGet Package Manager ->
Package Manager Console)
Run:
Install-package Microsoft.Net.Compilers -version 1.1.1
I had a large solution that was failing to build after updating to VS 2015 Update 1 RTM. In my case, there were a number of warnings of
Namespace or type specified in the Imports '<import name>' doesn't contain any public member or cannot be found. Make sure the namespace or the type is defined and contains at least one public member. Make sure the imported element name doesn't use any aliases.
that occurred right before "vbc.exe" crashed. Once I removed those extra, unnecessary Imports, the solution build correctly.
This issue is resolved in the latest Visual Studio 2015 servicing update. The relevant download is KB 3110221 which is discussed in this KB article.
In my case, I found that an import was causing the issue. Specifically, after trying a lot of other suggestions, removing the Microsoft.Office.Interop.Excel import from a file, finally got my project to built.
I had the same issue after installing Update 1 to VS 2015.
I've download Microsoft.Net.Compilers NuGet package as Brien King suggested in his answer. This fixed the issue for one project. And then:
"c:\Program Files (x86)\MSBuild\14.0\Bin\vbc.exe" had version 1.1.0.51109
...userprofile.nuget\packages\Microsoft.Net.Compilers\1.1.1\tools\vbc.exe had higher version 1.1.0.51202
So I've copied entire "1.1.1\tools" directory into "14.0\Bin" directory and overrided 27 existing files.
This fixed it for all projects. Remember to create backup before you do this.
After trying both Microsoft.Net.Compilers -version 1.1.1 and KB3110221, my solution was still failing to compile with the same error. Only later I noticed that the error was accompanied by a warning which was letting me know that one of the libraries referenced by the solution was compiled against .NET Framework 4.5.2 while my solution was compiling against .NET Framework 4.5. I recompiled the said library against .NET Framework 4.5 and the solution compiled fine.
Now that my issue was solved after trying three fixes, I can't tell whether the last one alone would have done, but I hope it'll be of help.
I fixed the issue by opening all my .vb files are removing extra imports. Do this for all files and then rebuild. This should work.
I started getting this immediately upon installing vs2015 due to a licensing disagreement w/ MS , which I lost. :-(
Freshly back to work, i encounter this issue.
I tried doing the NUGET suggested by Brien King. Problem persisted.
I tried doing the KN suggested by Teodor Constantinescu. Problem persisted.
I tried a new trivial web app and things were fine, so I did not uninstall vs2013 or vs2015.
I chose to back up my project (3 times, once on a usb stick i put in the other room) and delete groups of files and compile after each group was pulled out.
Ultimately, when I got close to the end (nearly an empty project) it compiled.
By adding groups of files back, I identified the single file that causes this issue. I can recreate the issue by uncommenting a single line.
Further commenting out code, I isolated the problem to 4 lines of code. Beautiful.
Explanation is this...
I have 2 web references that reference ssrs
THese are currently defined in my project as
SSRS_reportservice2010
and SSRS_ReportExecution2005
I struggled getting these to work, so over time i had different names as i deleted and readded the web references. (Padawan)
For whatever reason, a file that was EXCLUDED, got INCLUDED today (2013--> 2015 issue, or greg mouse farting issue? we will never know)
In that (mistakenly included) file, there was a pair of old references
'1 Imports SSRS_ReportingService2010
'2 Imports SSRS = SSRS_ReportingService2010
'3 Imports SSRS_ReportExecution
'4 Imports SSRS_E = SSRS_ReportExecution
Line 1 used to reference the WS now named in my app as SSRS_reportservice2010
You can unComment that and things compile and run. Note that you do get a warning that you are referencing an empty namespace.
Line 2 is of course an alias to the long name, because I am an extremely lazy typer, plus I insist my code be readable and long names stink IMHO.
Line 2, if uncommented , cause vbc error -2146232797
Note that uncommenting 2 , or 1 & 2 cause the error. Its something about the bad alias that causes compiler upchuck.
Repeat the above discussion with lines 3 and 4 which have to do with the webservice currenlty named SSRS_ReportExecution2005
So there you have it.
This took me 8 hours to debug. hope it helps someone.
Many of the other posts, comments, etc also mention Import/Using Statements. The root bug probably lies somewhere in there.... (yes, this is a bug in the compiler)
PS - one thing that was interesting is that the offending file's name started w/ a W so was one of the first to come out.
Nothing improved when I took that file out of the project all together.
I can not explain why the app did not compile as soon as I took the offending file out.
I can offer that I took the webservices out very late in the process, I just didnt think they were the issue.
It baffles me that the file could be gone and I was still getting the issue when I can now simply comment out 4 lines and things work perfectly.
Apologies for the second answer, but this one is much simpler.
I got the error again in a different project 8 days after last time.
This time, I started the day by giving a better name to a class.
I had a class named conversionFactors and I renamed that class to constants to better represent what the class held.
Immediately got the error
vbc.exe" exited with code -2146232797. SizingEngine
tracked it down to this line. I should have used the rename utility. yes. No argument. The compiler should also be more robust. Tsk tsk Microsoft.
Imports cf = SizingEngine.conversionFactors
so steps to reproduce
1. create a new project
2. create a class named Foo
3. create a class named Bar
in Bar, add the following line
imports bar_ = project1.NoClassByThisNameExists
click f5
listen for pac man wilting sound
ps - VS does not report any updates ready for download today. Im sure this will get fixed at some point.
I've just had this same issue. Mine was caused by having a class that had an event inside. I'd referenced this in another class as a shared property. The shared property was causing the compiler to fail. I removed the "shared" declaration and it compiles fine now
I encountered this error when I had a post build event that was throwing an error.
There was no indication this was the problem, just the -2146232797 error.
So check this in the property pages of the project. Go to Compile -> Build Events ... and check the Post-build event command line field. I suppose this might happen with a Pre-build event so check that as well.
The problem may be related with some utilized function in .NET Framework. Try to change the project framework to 4.0 and see if the problem persists.
I'm having troubles registering windows script file. When I'm trying to do so it says "Cannot find the type library for this reference Some.Reference"
Basically, behaviour is very similar to one described in this question Windows Scripting can't find reference but I can't figure out what to use instead of c:\path\to\control.dll.
In my case Some.Reference is Msxml2.FreeThreadedDOMDocument.4.0. so what should I actually do? I tried to use different kinds of msxml.dll, but it didn't seem to help.
Or maybe there are other ways to solve this issue?
One more detail: I managed to register this script on Windows7 but I get described error in Windows Server 2008 sp 2
Hans, thanks for your comment, because what I did is I used this tool
http://www.nirsoft.net/utils/registered_dll_view.html to view registered dlls and I found that the only abailable object I had is Msxml2.FreeThreadedDOMDocument.6.0 so I just changed my script to use this version, and as I can see from your comment it was not the worst decision
I'm a new on windows 8 store app development, I got annoying problem with this IDE first time after I installed it, everything works well but on the time I got this exception event there are no error on my code. I always got it with different number of exception but the message is completely same. Here are the picture :
what should I do to fix this thing?? I need your help, thanks
I received the same exception after updating to VS 13 Update 3. This solution worked for me:
Go to C:\Users\{user}\AppData\Local\Microsoft\VisualStudio\12.0\Designer\ShadowCache and delete all the contents in that folder.
Source: https://connect.microsoft.com/VisualStudio/feedback/details/797072/designer-crashes-in-visual-studio-2013-with-system-runtime-remoting-remotingexception
Try running Blend as an administrator. It sounds a bit like this issue.
If you are building a Windows 8 Store application, keep in mind that the System.Runtime.Remoting APIs are not available in WinRT. See MSDN for a listing of all the .NET APIs that are supported here: http://msdn.microsoft.com/en-us/library/windows/apps/br230232.aspx.
Try removing the remoting code and see if this resolves the problem.
I ran into this same issue when I started using a static object variable, where the object loaded images from resource. Somehow this tripped up Blend (perhaps garbage collection with static variables was getting confused).
To fix it I just moved that static object variable inside my Application class as a non-static member and accessed it via a public accessor function.
UPDATE - I also ran into this when one of my DependencyObject implementations was causing a stack overflow, updating one property when another changes and vice versa... Look for stack overflows.
Hope this helps someone!
I had this, right now. The reproducible cause was a crash of the Display-Driver triggered by my code. As this might only be the Display-Drivers fault, it might just needs fixing in the Display-Driver - for the meantime you can try to find the location causing the Display-Driver to crash and do a workaround. But the Display-Driver should not crash, whatever you throw at it. I see strange colours and splits in your screenshots. So I assume something makes your Display-Driver crash also.
I have been receiving the same error after updating Microsoft Visual Studio 2013 to Update 3
Designer works with a new project but removing the code in old projects does not work.
Deleting all folders in C:\Users{user}\AppData\Local\Microsoft\VisualStudio\12.0\Designer\ShadowCache worked for me...
The workaround posted by #pcnThird doesn't work anymore. The issue was resolved in Update 1 and subsequently in the latest Visual Studio 2013 Update 3.
I'm just in the process of moving from Visual Studio 2008 to Visual Studio 2010.
One of my projects use the Microsoft Fax Service Extended COM Type Library. After converting the project to VS 2010 I get the following compiler error:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.Targets(1558,9): error MSB3648: The Keycontainer-path "VS_KEY_812A0248FF872DEC" ist invalid. KeyContainer must point to an existing file.
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.Targets(1558,9): warning MSB3283: Wrapperassembly for type library "FAXCOMEXLib" not found.
I tried to remove FAXCOMEXLib from the project and adding it again, but it did not help.
I got a similar problem with other COM references.
How do I resolve this?
It is a known bug. Take a look at this Microsoft Connect entry which has a workaround.
this might not be relevant for you any more, but might be so for others. I've had the same problem recently and in my searches I found this list of common FAXCOMEXLib errors. I helped me, in any case.
I have a VB.Net solution that another developer created and I'm trying to compile it on our build machine (it compiles on their machine) but with one of the projects I get an error saying something along the lines of:
Imyinterface is ambiguous in the namespace anamespaceassembly.
I have tried with no success:
examined the references to see any obvious errors
removed and re-added the assembly in question
searched the system for the same dll
attempted to compile the original deve's src (.v the source control version)
examined the assembly with ildasm.exe
I usually code in C# and have not seen this error before (in this form at least), not that it is VB.Net specific but the UI for adding/viewing references is slightly different so I thought maybe VB.Net might do something different with references.
I also tried to compile on another machine, and it compiles ok. So I assume it is something with the build machine but I'm not sure what. Other conflicting assemblies somehow not referenced by the project, is that possible??
Any ideas?
Check your references if you have two versions of the same reference (eg. Microsoft.ReportViewer.Webforms version 10.0.0.0 and Microsoft.ReportViewer.Webforms 8.0.0.0) You will get this error. Delete the oldest and you should be good. I do this to myself all of the time.
There can be a few causes for this error. In VB, you should be aware that more names then you're used to from C# are available without class specification. Also, case does not matter in VB, which can further liken the chances on collisions.
Even in the event that you don't find the actual conflicting issue, you can resolve this in the same way you would in C#: rename it in the Imports statement:
Imports IM = yourAssembly.Imyinterface
Then change the code such that uses of Imyinterface are replace with IM.
NOTE: If the error does not point to a particular line, the conflict may be out of your hand. Normally, a full Clean Solution and Rebuild helps a lot, but occasionally a misbehaving file (i.e., another error) causes this error to popup first without clear source. Try to rollback recent changes to the place where it did work.
You also say it worked on another machine. Chances are that your machine is having a different version of MS Visual Studio or .NET. Check and compare the exact versions.
I was facing same issue. I upgraded my application from vb6 to vb.net and when i change the build configuration from DEBUG to RELEASE then i got AMBIGUOUS errors.
I found dulicate references folder in solution Explorer. I removed those duplicate referecnces and Build sucessfully. I Hope it may help others.
Thanks for the responses! I tried each but still was having issues.
One point of info I left out of the original question was that the VB.net projects are upgrades from VB6 projects. At the time I did not think that was relevant.
After investigating further the build machine was used to build the VB6 projects also. So I ran 'reg32 /u' on the vb6 dlls and that seemed to fix the VB.net issue.
Not exactly sure why this fixed it since I was not referencing the VB6 dlls, I'm guessing something to do with ambiguous entries in the registry confusing the vb.net project.