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.
Related
I'm running into a weird issue with a VB.Net project using the MySql ADO.Net connector. I have the following code:
Dim param As New MySqlParameter("#val29", MySqlDbType.DateTime)
And I'm getting the following error message:
Ambiguous invocation:
Public Enum member Datetime As MySqlDbType (in Enum MySqlDbType)
Public Enum member DateTime As MySqlDbType (in Enum MySqlDbType)
match
The difference between them, if you notice, is that DateTime is in a different case then Datetime. Since this is VB.Net and VB is case-insensitive, I'm not sure why I'm getting this error.
Interestingly enough, I opened Object Browser in Visual Studio 2013 and, as you can see from the image below, there does seem to be two definitions of DateTime:
.
Thinking maybe there was an issue with the DLL, I went to their website and downloaded the source code and rolled my own DLL. Same issue. I couldn't seem to find anything on the Internet about it, except for this page, which describes my issue exactly, except it seems to be due to a specific bug in Visual Studio 2015. I'm using Visual Studio 2013. That almost makes me think a Windows Update came along that changed the way the VB.Net compiler works. That doesn't make any sense though because updates are specific to Windows, not Visual Studio. Anyone have any ideas?
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
This problem is pretty self explanatory. Here are the details: I'm trying to include freeglut and glew in Visual Studio 2012 on Windows 8. I'm on a 64 bit system, so I thought I needed to put glew32.dll in my 64 bit system folder. I tried that and receive the following error:
"The application was unable to start correctly (0xc000007b). Click OK to close the application."
Which I've interpreted as I'm trying to put a 32 bit dll in the 64 bit folder or vice-versa.
Just for laughs, I tried putting the file in System32, but of course, it just told me the file wasn't on my computer. Any suggestions?
EDIT* May I also add that some of the set up for this was NOT the same as it would have been on Windows 7 or Visual Studio 2010 or earlier. I may have missed something because I kind of winged it using the search function combined with some documentation I found on various websites. (i.e the lib and include folders are no longer in the same place)
EDIT2* I'm sure this can probably be derived, but I want to add it anyway for clarity: If I removed the dependency for glew32.lib and comment out any code using glew.h, the window forms as it should. I don't think my source code is needed seeing as I'm 99% sure this is not a code issue, but if anyone wants to see it, let me know and I'll attach it.
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
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.