I am trying to troubleshoot a VB.NET project that contains UserControls (actually, several of them that are displaying the same issues). I am trying to get them to build under x64, but it is impossible. In x86 or AnyCPU, the UserControl builds and shows up in the Toolbox, so I can add or modify it in the forms that require it. In x64, the controls disappear from the Toolbox, I get warnings during build (the current project builds though), I can't see any of the forms - I get errors (please see below) - and projects that require the project with the form as an import will not build.
When I was studying what these UserControls are so that I can maybe rebuild them from scratch, I downloaded code from a book - great learning tool, but I get the same errors:
Could not find type 'Chap15SampleCode.ListSelector'. Please make sure that the assembly that contains this type is referenced. If this type is a part of your development project, make sure that the project has been successfully built using settings for your current platform or Any CPU.
The variable 'ListSelector1' is either undeclared or was never assigned.
I also get warnings, not sure what to do about them:
Possible problem detected while building assembly 'Chap15SampleCode': Referenced assembly 'mscorlib.dll' targets a different processor
Possible problem detected while building assembly 'Chap15SampleCode': Referenced assembly 'System.Data.dll' targets a different processor
I checked and found System.Data as a Reference is in c:\Windows\Microsoft.NET\Framework... (if I change the target framework to 4.0 the Reference is in c:\ProgramFiles(x86)... that was what my projects had ... and I tried to change it because of the x86, I couldn't, I had a few others in ProgramFiles(x86) and I thought that may be the problem ?)
Reinstalled VS2010, reinstalled Windows - did the same before btw - but I do have a clean system so I can't blame it.
If I can get this simple project to work, I hope the real projects will be easy - Please help me figure out what this is about. Thank you.
You have changed the Platform target setting in the project to x64. This is not appropriate for any project that produces a DLL. The actual bitness of a process that uses your DLL is determined by the EXE that starts the process. Or the host in which your DLL runs, the case for Visual Studio which is a 32-bit process. There is nothing a DLL can do to force the bitness, it can only refuse to get loaded. Which is what you see happening.
Change the setting back to AnyCPU so that your UserControl will work correctly in any process, regardless of its bitness. Including the VS designer. Project + Properties, Build tab. For VB.NET it is located in the Compile tab, Advanced Compile Options button.
Related
I'm forced to use a third-party COM component in an application, and I'm having issues adding the reference to my project.
I've added this DLL as a reference to a project before, but in the past it would link directly to the DLL, such that the "Path" in the reference's properties would be filesystem path where the DLL was installed (i.e. not relative to my solution's directory). However, now, when I add the reference, the "Path" is to my project's obj directory, "Embed Interop Types" is set to True, and it's listed as an ActiveX component (which is not correct).
Then, I stumbled upon this MSDN article, which says:
If you want to add a reference to a registered COM DLL that contains an internal manifest, unregister the DLL first. Otherwise, Visual Studio adds the assembly reference as an ActiveX Control instead of as a native DLL.
Well, there you have it. That's my exact problem. I need the native DLL, but I'm getting an ActiveX Control instead. So, I did as it suggested and unregistered the DLL. However, when I then try to add the reference, I get an error saying:
A reference to ... could not be added. Please make sure that the file is accessible, and that it is a valid assembly or COM component.
If I register the DLL again, I'm able to add it as a reference, but again, it's added as an ActiveX control. At this point, I don't know what else to do. Microsoft is very clear that I must unregister it before adding it as a reference, but then Visual Studio 2013 apparently won't let me add an unregistered DLL. Any one have any idea how to work around this?
UPDATE
So, apparently a recent update to this app made COM the only option (no directly using the DLL). The fact that it was added as ActiveX didn't mean anything. The problem turned out to be that this was a 32-bit library trying to run in 64-bits. I knew that was a potential problem, but switching the platform target to x86, still resulted in an error so I ended up chasing a red herring. Turns out IIS Express 8 runs natively as 64-bits even if the platform target of the site you're debugging is 32-bit. I had to go into Visual Studio options and uncheck the flag that tells IIS Express to run 64-bit (under "Web Projects") and then everything ran fine.
So, since adding the registered DLL was pretty much a no-go, I focused instead on trying to figure out why Visual Studio wouldn't let me add it when it was unregistered. I mean, sure, I might get an error about it being an unregistered DLL once I tried to run the project, but it should at least let me add it as a reference, regardless.
I eventually stumbled upon tlbimp.exe, which according to Microsoft:
The Type Library Importer converts the type definitions found within a COM type library into equivalent definitions in a common language runtime assembly. The output of Tlbimp.exe is a binary file (an assembly) that contains runtime metadata for the types defined within the original type library.
Okay. Well anyways, I opened a Visual Studio Developer Prompt (regular cmd doesn't have tlbimp.exe on the path), and ran my DLL through it. It created a new DLL, which I was able to add as a reference, and it satisfied my project dependencies. However, I haven't tested it just yet to make sure everything still works as it should once this thing is running, so I'll update with what I find there.
UPDATE
Yeah, so this doesn't work either. I get the same error once it's running saying that the class is not registered. Only now, I can't register this DLL because tlbimp.exe removes the entry-point.
I have a DLL written in C# and set for COM visibility. I have it setup as a side-by-side assembly and can successfully deploy the application to client PCs registration free. My question is related to the development PC. Is it possible to compile against the DLL in a similar registration-free manner or is registration required on the development machine? I have tried adding the DLL directly though the Project -> References menu and get an error stating "Can't add a reference to the specific file." The DLL is sitting in the same directory as the .vbp file and I have tried adding the DLL both with and without the client app manifest being present.
I have tried adding the DLL directly though the Project -> References menu
That adds a reference to a type library. A type library is a language-independent description of the types in a COM component, VB6 uses it to know how generate efficient code and to provide type checking and auto-completion. A type library is the exact equivalent of metadata in a .NET assembly.
Traditionally, and the way VB6 did it, the type library was embedded as a resource in a DLL. So you are probably used to picking a DLL in the dialog. That however doesn't work so well when the DLL is generated by C#, the type library can only be generated after the C# code is compiled. You have to pick the .tlb file in the VB6 dialog. The traditional way starts with the COM component being described in the IDL language, the type library can be generated before the code is compiled so can easily be embedded in the final DLL. It is technically possible to do it in C# as well, but the build steps are very laborious and painful, you essentially have to build the DLL twice with different build commands.
The type library for a C# library is normally generated in one of three ways:
Using Project + Properties, Build tab, "Register for COM interop" option. This requires VS to run elevated so it can write to the registry. You start VS elevated by right-clicking its shortcut and picking "Run as Administrator"
By running Regasm.exe, using the /tlb:filename option. An alternative for the 1st bullet and necessary if you don't want to run VS elevated for some reason. Using the /codebase option on your dev machine is also wise to make it work exactly like the 1st bullet and not require putting the DLL into the GAC with gacutil.exe
By running the Tlbexp.exe utility, the type library exporter for .NET assemblies. No registration is done, it only generates the .tlb file.
The first bullet is the normal choice and very desirable because you can never forget to update the type library this way. It is perfectly fine on a dev machine since you only really care about reg-free deployment on the user's machine. You probably got into trouble by not doing this anymore.
Using the 3rd choice is okay and more compatible with your goals, run Tlbexp from the Visual Studio Command Prompt. Just keep in mind that you have to do it again when you make changes to your C# code. Forgetting this once and losing clumps of head-hair trying to figure out why your C# changes don't seem to be effective or getting hard-to-diagnose error codes gives you lots of reasons to consider the 1st bullet again :) You can emulate the reg-free scenario by running Regasm.exe with the /uninstall option.
I am currently converting a library to be a Metro library for Windows 8. I've created a brand new project in Visual Studio 2012 using the "Class Library (Windows Store apps)" C# Template. I've been adding a lot of files and working through the compile errors, but the one that's confusing me is:
Error 2 Predefined type 'System.TypedReference' is not defined or
imported CSC MyNewProject
The "CSC" appears under the "File" column. Double-clicking the error does nothing. Googling only gives me this:
Do not specify the /nostdlib option from the command line compiler.
Make sure that the project refers to the correct mscorlib.dll.
Reinstall the .NET Framework common language runtime (if the previous
solutions do not solve the problem).
(source http://msdn.microsoft.com/en-us/library/f5c3ehka.aspx)
I'm not using a command line compiler, I don't know how to include or exclude mscorlib - because unlike previous .NET apps in Visual Studio, the only thing my project references is ".NET for Windows Store apps" and "Windows" (something I'm still getting used to).
Any thoughts/advise on this?
That Object is not available or has been relocated for the new ARM .NET architecture.
Here is the Full API for you to search, I would of searched for it, but it is missing a search func.
http://msdn.microsoft.com/en-us/library/windows/apps/br211369.aspx
For anyone else who encounters this, I experienced this while I was converting a project to run on metro. I continued to fix other issues (at the time this was one of hundreds of errors) and eventually this just simply disappeared. My plan was to eventually compare this to a new metro project in a text editor once I fixed all the other errors, but it solved itself before that could happen.
I have Visual Studio 2010 installed and have a project I got from someone else which I can build successfully without any errors. I get a Wrapper.dll,
which I would like to access using JNA.
I am using Win7 64-bit.
But I get the error: java.lang.UnsatisfiedLinkError: Unable to load library 'Wrapper': The specified module could not be found.
Wrapper.dll of course is in the correct folder and it is a 32-bit dll and my Java program also uses a JRE with 32-bit, so this is not the cause of the error.
I used DependencyWalker to check whether *.dlls are missing:
MSVCP80.DLL
MSVCR80.DLL
GPSVC.DLL
IESHIMS.DLL
And yes there are some missing.
Can I conclude that the error is related with that these DLLs are missing?
But why does Visual Studio compile correctly then and does not throw an error?
How to solve this in order to access these functions in Wrapper.dll?
I also read that downloading dll's might not be the right thing to do!
(I know that Wrapper.dll relies on another dll or sourcecode which was built in Visual Studio 2005, if that is of interest.)
EDIT:
I found out, that Wrapper.dll relies on three other dlls which probably were built on MSVS2005. These require the above mentioned DLL's (checked with dependencywalker) and I guess therefore Wrapper.dll also links them.
So what do I actually do to get rid of these old dll's?
Would I need to build the other three DLLs with VS2010 or
is this a problem which always will appear, meaning, that you need to copy paste old DLLs in order to use the precompiled Libraries which are dependent on those.
Is there a way, that the program would run on any other system as well without copy pasting these DLL's?
All required DLLs must be available to the system for loading. If you define jna.library.path, that is where JNA will look for the initially loaded DLL, as well as any dependent DLLs. In addition, java.library.path (which is essentially PATH) will be searched for dependent DLLs.
MSVS often uses paths in addition to PATH when building, debugging, and running code within that environment.
Solutions:
a) remove dependencies you don't really need; this may include telling MSVS to build your DLL differently
b) include non-system DLLs next to your custom DLL (or include their location in PATH/java.library.path)
EDIT
a) you can include the offending DLLs in the same directory as yours. this is fairly low impact on the target system, but if they are DLLs that are expected to be on any system, you shouldn't have to do so. It's preferable to adjust java.library.path so that all system DLLs are accessible.
b) you can recompile your dependent DLLs and be more careful about backward compatibility and explicit linkage. Depending on features used by the DLLs, though, you may not be able to remove the dependencies.
MSVC[RP]80.DLL are C and C++ runtimes, respectively; you may or may not be able to link against a previous version.
IESHIMS.DLL is part of IE and should be on the system, but likely in a path inaccessible to your program.
GPSVC.DLL has to do with group security policy, so it should be available on the system (modulo whenever the DLL was introduced).
I wrote a program in C++ using Visual Studio 2010
But when I run it on some computers with WinXP it says
"Cannot start because MSVCP100.dll wasn't found"
How do I prevent such dependencies on dlls that do not come with windows?
Thank you.
you cannot prevent this dependency, as it's the core runtime library of Visual C++. Instead, include the Visual C++ 2010 Redistributable package with your application (usually a separate link is enough since most people have it installed already)
However, if in fact your program cannot start because a dll with D at the end such as MSVCP100D.dll then you need to build your program in release mode, which by default switches the run time to a non-debug version. You need to be careful to nut out any other included static and dynamic libraries you're including in your project to make sure all debug or all release versions match for your builds.
If you are having trouble finding which sub-projects are referencing the debug versions, you can download and run depends.exe and browse through the exe file to see.
Sorry for the late respones, but yes you can prevent this dependency, just go to solution property of yopur project, go to C/C++ > Code Generator and in Runtime Library change it from MDd to MTd, will include statically the dependent libraries, and not in run time, like this avoid Run time errors while try to run the Dll.