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.
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 have an application which relies on several libraries built by other people in my organization, one of which has stopped working. I get this error in the command-line:
Unhandled Exception: System.IO.FileLoadException: A procedure imported by 'XXX.dll' could not be loaded.
I opened up Dependency Walker to try and track down the source of the problem, although I should say that I am brand-new to Dependency Walker and I don't really know what I'm doing. Here's what I see in the log window:
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Which seems straightforward, except:
Due to my unfamiliarity with DW, I can't seem to find what module this error is actually referring to
The same DLL that ships with old version of the application, which still works, shows the same thing in Dependency Walker
The only difference I can find between the old and new DLL is that KERNEL32.DLL shows up as red in the newer one, and the function K32EnumProcessModules appears as red (not exported). This same function does not appear at all (green or otherwise) for the old DLL.
To summarize so far: one DLL works and the other doesn't; both show up as 'bad' in Dependency Walker, but in only one does the function K32EnumProcessModules appear as no good. I do not know if this function is what is causing the "unresolved import" error and would like to find out.
The only change in the application I have made that I think could've caused this is upgrading the runtime from .NET 2.5 to .NET 4. This upgrade was made for reasons unrelated to this DLL, and should not affect it: the DLL does not make any calls to .NET components higher than 2.5, and other people in my organization using the same library have reported that it works fine with .NET 4.
I realize I'm providing sparse information, mostly because I'm not sure what information will help troubleshoot this problem. Please let me know if there are tests you'd like me to perform to find out more.
Probably releated to this https://blogs.msdn.microsoft.com/vcblog/2009/08/27/windows-sdk-v7-0v7-0a-incompatibility-workaround/
Defining PSAPI_VERSION=1 might help.
I'm seeing a strange build bug a lot. Sometimes after typing some code we receive the following build error.
Class 'clsX' must implement 'Event PropertyChanged(sender As Object, e As PropertyChangedEventArgs)' for interface System.ComponentModel.INotifyPropertyChanged'.
And
'PropertyChanged' cannot implement 'PropertyChanged' because there is no matching event on interface 'System.ComponentModel.INotifyPropertyChanged'.
Those error should never go together! Usually we can just ignore the exception and build the solution but often enough this bug stops our build. (this happens a lot using Edit and Continue which is annoying)
We're using Vb.net and c# mixed in one big solution.
Removing the PropertyChanged event and retyping the same code! sometimes fixes this.
Question:
Has anyone else seen this problem and has some suggestions how to prevent his?
We're using a code generator that causes this error to surface but just editing some files manually triggers this exception too. This error occur's on multiple machines using various setups.
Someone had the same exact issue discussed here. It sounds like there is an issue with this build picking up an old version of a binary. I would try the following in order:
Verify all assembly references use project references where possible within the Visual Studio solution.
Disable build parallelization in case there is some weird file locking issue with concurrent project builds. Go to Tools -> Options, Projects and Solutions -> Build and Run, then set "maximum number of parrellel project builds" to 1. Not the best solution but it may help narrow down the problem.
Disable the Hosting Process in case it's locking some file causing an assembly to not get rebuilt correctly. For C# project go to Project Properties, Debug tab, and uncheck "Enable the Visual Studio hosting process". For VB.NET project you'll need to Unload Project, Edit the project file, and add <UseVSHostingProcess>false</UseVSHostingProcess> to the PropertyGroup of each configuration. Again, not the best solution but you probably won't notice a difference.
Lastly, try doing a Clean + Build to try and resolve the issue when it occurs (I know this is not a fix but it's easy enough to do), also Rebuild may be slightly different than Clean + Build so try the latter if the former doesn't work.
As I can not comment due to lack of appropriate points.
But I would like to share one of my experience:
In an aspx.cs page I was working, used to compile fine and some time gave mysterious error of a variable not defined or function not defined or sometime variable or the function defined two times. I changed possibly each and every variable and function name but there seemed no effect , but after entering a simple space or a new line at any place in the file used to solve the compile error. At one time I tried to save the file (in a different encoding as i am used to experiments) and found that the file was not saving in the correct encoding (i.e. the ansi encoding because the file had a unicode character ), I removed the unicode character and that compile error didn't bothered me again.
This unicode character problem could be (not a hard and fast rule) there so you could check it.
Nuke & restore using source control (TFS instructions here):
Make sure you have everything checked in
Exit Visual Studio
Rename the project directory to .Bak (effectively deleting it)
Reopen Visual Studio and in source control:
Get Specific Version
check 'Overwrite... not checked out' and 'Overwrite ... even if local version matches'
Re-open project
Another problem: Make sure some source files are not newer than the current date (or your date is set back). Often this happens in apps where you are doing logic that requires certain things to happen differently on certain dates. You change your clock to test it, make a revision to the source with the date advanced, set the date back, and viola, rebuild does not rebuild that file.
You say 'typing it in again' - can you try just saving? After 40 years since MULTIX the .net build still decides what has changed by checking the file timestamp.
good luck!
When you get the error, is it always on the VB calling C# side, or vice-versa, or does it work both ways?
If the answer is either of the first two situations, try building the "callee" project within the solution before building the "caller" project to see if it stops the situation.
Also, just in case it may jog something for you to think about, does this error crop up when you change a VB file or a C# file, or is there no correllation?
Oh, and sorry this looks like an answer instead of a comment, I cannot post comments yet (need 50 rep).
I have a Microsoft Word template with some code and some references, that has been working fine for months but has just started throwing up a spurious "User-defined type not defined" error whenever I open it or try to compile it.
I know it's a spurious error because I haven't made any significant changes to the code. In fact, I've rolled the code back to the last deployed version (which I know works fine) and I still get the error. I've also commented out all the code in the template and I still get the error. I've also removed and re-added all references (same error), and removed all the references and added them back, one by one, until the resultant compile errors are resolved, at which point I'm left with the spurious "User-defined type not defined" error. (I'm going to call this a UDTND error, from now, to avoid driving you all mad.) I think the error started popping up after I rebooted my PC. It only happens with this template, but I don't see how it can be anything to do with this template.
Interestingly, the error is subtly different from a genuine UDTND error in the following ways:
No code is highlighted when the error is displayed.
The dialog is titled "Microsoft Visual Basic", and contains the error message but, unlike a real UDTND error, doesn't contain the text "Compile error:";
It happens when the template is opened, not just when it's compiled (at least, I think that's different from a normal error).
I've tried Googling it but I just get a bazillion results from novice developers asking why they get this error, with responses telling them that they either need to declare the missing type, correct the spelling of the offending variable type, or add a reference to a missing library. I've been banging my head against my screen all afternoon, and that's helped about as much as all the other things I've tried (i.e. not at all). I have a feeling that this is something to do with a messed-up reference, but afaict they're all fine, and I've removed and re-added them, which I would expect to resolve that sort of problem.
Any ideas...?
Your trouble-shooting on References is sound. Once upon a time (and I don't recall the precise error) I was at the same point, and the reference ordering was the key. When you're designating References, you'll notice a "Priority" adjustment feature. Experiment with that and you may solve this.
I have had "User-defined type not defined" problem on several occasions when compiling Microsoft Visual Basic 6 (MSVB6) code that was compiling without a problem earlier. It seems to happen after I have had a long coding session without rebooting the computer. As you can guess, I have been using Microsoft operating systems. I currently am using Windows XP. Rebooting the computer usually fixes the problem as it so often does on Microsoft operating systems.
I have read that fully qualifying declarations also can help, e.g., "Dim oBar as Foo.Bar" instead of "Dim oBar as Bar". I have not tried this approach however.
I had a very similar problem.
My problem appeared (I think) just after I made a Search and Replace that I canceled (Ctrl+Z). There was not highligting of the problem, only the ""User-defined type not defined" error message when I compiled.
I tried:
1) restarting computer
2) changing reference ordering
3) removing functions/procedures, modules one at a time.
Didn't work. My project was written in Excel VBA and here was the solution I found.
THE SOLUTION:
I opened a new Excel file and opened the Visual Basic Editor. I then copied all Forms, Modules, and Class Modules one by one into the new file. I then Copied the Control Objects (3 Commandbuttons) from the old sheet into the new one. Now the new file was identical to the old project - only the ""User-defined type not defined" had gone and problem was solved.
Yea references would be the first step in troubleshooting this problem as already stated, but failing that id start commenting out the code in any event procedures running at start up (my experience is only with Access VBA though)
I had the same problem with Excel 2013.
It started when I did a search and replace on the name of a Custom Class.
I changed the name of the Class after I did the search and replace on all references to it and the spurious error started immediately after that.
I reverted to an earlier version ad confirmed that the problem was not there and then did the same search and replace and re-name and got the exact same behaviour again.
The Custom Class that I changed the name of only had one consumer and it was also a custom class.
I exported, removed and re-loaded the sole consumer class and the problem was fixed.
Check out this link for a Microsoft bug that might be related.
TLDR:
The reference to a package/addin/whatever probably needs to be re-referenced. Check Tools -> References in the Menu.
Also it appears that if you install Microsoft Security Advisory 960715, that certain controls are killed. There are fixes which may or may not work for you. A good article is on this blog:
VSOD Blog
I've got a really strange error and any light that anyone can shed on this would be greatly appreciated.
I made some changes to some VB6 source which builds a COM object. The automated build which builds our app returned an error. No problem I thought--I'll just back out my changes. Well backing out my changes isn't making the problem go away.
Specifically when I attempt to build the app via a .vbg file, with a command line like path\to\vb6\vb6 ProjectFile.vbg /make
I get a message
"Compile Error in File '', Line : Object library
invalid or contains references to object definitions that could not be
found."
As I said, I reverted the source code so I'm really stumped as to why this error is still occurring. Any VB6 gurus around who might be able to point me at an answer?
I can post the exact code in question but the fact that it was building correctly, stopped building correctly and now refuses to build correctly makes me think this is not a problem with my code but rather some problem in the environment. Like something got put in the registry as a result of the previous build error.
Any tips, hints, or suggestions greatly welcome. I realize my question is a bit sketchy but I'm not even sure what's important to include and what isn't.
EDIT 1:
Thanks for the excellent suggestions guys. I think it is something to do with VB6 doing some sort of auto-registration.
Just to add a bit more detail: this problem does not occur when I build the referenced vbp file from the IDE. It only happens on the make on the .vbg which contains the vbp. Also the build tool in question automatically pulls latest source and the error happens on both my local box and the dedicated build box.
EDIT 2:
Hi again all,
The release engineering fellow figured out how to get this to build in his build environment so it's currently ok. Once we're past this crunch, I'll try to interrogate him about what he did and share the details with everyone.
Thanks again for all the great suggestions. This is what's so great about SO; that is, I asked about a 10-year-old technology and I got several great and on-point ideas.
Make sure that the VBG and all the VBP's got rolled back as well. That error is consistent with a project trying to reference a CLSID that is no longer valid for the dependency. Have you tried loading up the project group and building from the IDE, if that works and you save and check in all the changes to the group and project files, you might be fixed up.
I'm guessing the fact that you mention that it was a COM component might be the source of the problem. If any of the public method's or properties have changed then I seem to remember that VB6 will change the interface GUIDs and auto register the new ones.
My suggestion would be to check the registry to look for any mention of the component name, make a note of any associated CLSIDs, back up the registry, and then delete the references.
As cmsjr mentions it could also be a bad CLSID reference in your .vbp files.
The other option is that the failure has caused a problem with some .tlb (type library) or olb (object library) files.
The best thing to do is move all your compatibility DLL to a separate and combined directory. The reason for this is control over what VB6 is using to check for binary compatibility. In addition the Typelibs that are generated IMPORT the references. So if you using Binary DLL Ver 10 for compatibility however the import is pulling in Binary DLL Ver 9 you will have issues. By keeping all the libraries in a single folder and pointing your projects to the DLLs in that folder you ensure that the respective TypeLib Import the correct version.
Finally if you have multiple levels of DLL reference each other. You may run into mysterious error where the VB6 is unable to compile using binary compatibility. In such cases you need to compile the lowest DLL in the hierarchy (Utility DLL perhaps) copy it over into the compatibility folders. Work your way up the chain until everything compiles in one shot again.
This is because if have DLL A reference DLL B which Reference DLL C. VB6 will get sometimes get confused if you make a change to A and C. will compile fine but A will not until the compatibility libraries are updated.
Hunt down and delete any .obj and .exp files that may be lying around from the previous failed build.
You will have to open the project & re-type in the lines that you changed.
Save the project alongwith VBG and re-compile after that.
I think that will fix it.
EDIT: The idea is that the cls/bas file remember the class (CLSID) that you used. So, if you change the references but don't change the lines in the cls/bas - it is a mismatch of type (what was referenced vs what is typed in cls/bas file).