I have an EXE in VB6 that calls a recently upgraded to VB.Net DLL. This part is working fine, but the issue that I am running into is related to locating the interop of another COM DLL the VB.Net DLL references.
An overview: EXE (VB6) calls method A of DLL (VB.Net), no issues. Method A of DLL calls method B of third party DLL (COM), it gets an error of not being able to find the interop file of the COM DLL.
I have tested directly in VB.Net using a test UI to call the same method A in the VB.Net DLL, and everything works fine. I am currently at a loss as to what is causing the issue.
Thanks,
Chris
I have finally found the answer to the issue. All said and done, the issue was that the interop assemblies were framework version 4.0 instead of framework version 2.0. Visual Studio created them this way for some reason, so I had to change them by using Visual Studio 2008 to create new versions of them.
The process to find this out (which most of is already stated above, but repeated here for helpfulness) was to place all my VB.NET dlls and the interop assembly dlls in the directory of the VB6 exe. (I created sub folders for each one for easier cleanup later.) This still resulted in the same error, but the assembly builder log showed a different reason for the error. This time it was able to load the assembly without issue, but was not able to complete the setup of the assembly.
Researching this led me to the idea of checking the framework versions of the interop assemblies using ILSpy to find out they are version 4.0 while my dlls are version 2.0.
Initially I tried recreating them in Visual Studio 2017, since my project uses framework 2.0, but it still created them as framework 4.0 for some reason. I then tried in Visual Studio 2008, and it was able to create the correct framework 2.0 versions of the interop assemblies, and now everything works as expected.
Related
I intend to build simple Winform application just to allow user to automate their file creation and store the last filled form in a file to keep it for next run.
thus, I'm not interested in creating installer for this simple Winform application. I expected to only compile it to .exe and let it run on other computers.
I develop the application using VS2019 community with target .net 4.6.1
It won't run on computer with Windows 10 with only .net framework 4.8
We are not able to install framework 4.6.1 since it says an earlier version of .net framework is already installed.
Should I recompile my application with target .net framework 4.8?
Can't I compile my application to run on any computer which at least has 4.6.1 or newer? without installer.
(I don't really understand the .net framework backward compatibility truly mean)
my application uses:
library of user32.dll for SetForegroundWindow function
to create .ini file
Finally it works. Even compiled to target .NET 4.6.1 still work on .NET 4.8 computer actually.
The issue is because my application is targeting to another application using interope COM interface, while the license is not sufficient for the user to allow COM interface.
we notice it when we finally create a pure simple windows form, then step-by-step compiling while adding each feature.
Sorry Every Body for this silly case. And my special apologize to evry1falls for spending your time.
I'm thinking to change this Question or delete it. because it is not the issue at all
The Actual Issue is:
I created Windows Form Application starting from a blank Project. And I don't know that the .NET Unhandled Exception is not activated by default.
When created from Windows Form Project Template, the Unhandled Exception message shown.
I created another Question about it: Here
I've written a DLL that provides methods for extracting data from a MySQL DB and generating a report using the built-in report viewer in VS 2012. The idea is to use this in a VB6 program. I've gone through the following process:
1) Build the DLL in VS with "register for COM interop" selected
2) Placed the DLL and TLB file in the directory of the VB6 program on another machine
3) Used regasm: "regasm Report.dll /tlb: Report.tlb /codebase" (redundant step if I already have the TLB file generated by VS?)
4) Added the TLB file to project references in VB6
The VB6 program builds and executes okay, but when I got to run my report I just get "Automation error: the system cannot find the file specified".
I've gone through the above process for a trivial DLL according to the instructions given here. This worked fine. I suspect that the references used in my DLL (MySQL.Data and Microsoft.ReportViewer.WinForms) may also need to be registered on the VB6 machine. I've been able to do this with MySQL.Data but not the ReportViewer DLL.
If it makes a difference, the DLL was built on a Windows 7 64 bit machine whereas the VB6 machine runs XP 32-bit.
Thanks in advance.
Turned out the problem was that I needed to set the Copy Local property for Microsoft.ReportViewer.Common and copy the relevant DLL files along with my own DLL. Hope this helps anyone with a similar problem.
Here's the situation:
We have classic ASP running for our site.
We have VB6 DLLs, running inside the ASP as COM Objects.
I have moved over to Visual Studio 2008. I am trying to create DLLs that I can utilise in ASP the same way we would with VB6 (Server.CreateObject("")). Unfortunately, although registering is successful, I get a:
"The call to Server.CreateObject failed while checking permissions. Access is denied to this object." Error.
I have done plenty of research and found that you must register the VB.NET DLL with 'regasm' (which I did) you also need to tick the appropriate ("Make assembly COM-Visible") box.
However, through all my efforts, it seems I have run out of luck.
I did read something about having a class template called "COM Class" in order to create COM DLLs in VB.NET, but I do not have that option in the template choice.
So my question is, do I change to visual studio (non-express to obtain the COM class template and if so, would that definitely work?)
OR
Is there something that I am not doing correctly?
Please note moving to ASP.NET is not an option, nor programming in VB6.
Thanks!
EDIT
After about a full week of searching, I have found the answer, for anyone who finds this page: http://social.msdn.microsoft.com/Forums/en-US/9f84bdf7-aace-4a57-a3e4-3863a0efb647/how-to-create-comvisible-dll-that-i-can-use-from-vba-using-vs-express-2008-beta-2
man you have to read about .net a lot.
you cannot just write a .net dll and then use this in classic asp. These are two completely different Technologies.
it has absolutely nothing to do with visual Studio. Visual Studio is just the development Environment and has absolutely nothing to do with your .net Framework or your web application. you cannot use visual Studio > version 6 for vb6 programming. so you cannot create vb6 dlls with visual Studio 2008n or 2010 or 2003 or 2005.
you can write .net dlls and use them in classic asp or any other com Aware Technology. but they are still .net dlls which require the .net Framework. they are just com visible.
that is a bit complicated but possible:
you classes and methods have to be "com visible" you achieve this by using the Attribute [ComVisibleAttribute( true )]
just before the declaration of your class and before every method you want to be com visible.
example:
[ComVisibleAttribute( true )]
public class Helper {
public Helper() {
}
[ComVisibleAttribute( true )]
public object parseDate( string strDate ) {
return (object)DateTime.Parse( strDate ).ToString( "dd.MM.yyyy HH:mm:ss" );
}
}
you have to use an emtpy constructor for your classes!
furthermore you have to check "Assemlby Com visible" in Project properties-> assemblyinformation
or open Properties/AssemblyInfo.cs and add These lines:
[assembly: ComVisible( true )]
[assembly: Guid( "e2e1670d-1f90-4948-98be-27cc820b4675" )]
after you have build your dll you then have to use the ragasm.exe to Register the .net dll in the registry. (normal .net dlls are note registeres n the registry by default.
you can do that like so:
%windir%\Microsoft.NET\Framework\v4.0.30319\regasm.exe path/and/Name/of/your.dll /codebase
you have to make sure that the path to your wanted .net Framework is correct.
after that you have to restart your iis and can then use the .net dll methids from classic asp.
please be Aware that you can only pass and return values of simple datatypes to your .net methods from/to clasic asp like string, int etc.
Answer:
http://social.msdn.microsoft.com/Forums/en-US/9f84bdf7-aace-4a57-a3e4-3863a0efb647/how-to-create-comvisible-dll-that-i-can-use-from-vba-using-vs-express-2008-beta-2
Built the .dll, and targeted .NET Framework 3.5, making it COM visible.
Used the GAC utility that was installed with the Visual Studio 2008 Beta 2 (and hence >.NET Framework 3.5) - it was in C:\Program FIles\Microsoft SDKs\Windows\V.0A\bin - to place .the generated .dll into the GAC
Used the regsam.exe file I found in c:\ Windows\Microsoft.NET\framework\V2.0.50727 to >register the generated .dll.
Used the tlbexp.exe file I found in C:\Program FIles\Microsoft SDKs\Windows\V.0A\bin to >.export a .tlb file
In the VBA IDE, used Tools->References to browse to the .tlb file and select it as an >addtional reference.
The problem was that i was not doing step 2 or step 4.
I hope this helps someone in the future as it took me very long to solve.
I'm working with some application handed over by another person in which I must document the requirements, build and deploy processes.
The problem here is that Visual Studio (2005) is throwing a lot of errors since it can't find the references for the dlls.
This obviously won't let VS build the project.
Everything works fine on the persons computer but not on mine, even though the project references the same folder where the dlls are, the bin folder.
How can I circumvent these problems and get VS to properly reference the dlls?
The following printscreen shows the references screen for the project.
My guess is that your DLL uses a more recent .NET framework than your application does.
Check the properties for your DLL source (right-click on the DLL code in the solution explorer and choose Properties). Go to Application - Target .NET framework and compare the version to the one the application itself uses (right-click on the project code). Note: under your application properties check both the settings under Application - Target .NET framework AND under Publish - Prerequisites.
For what it's worth, even after changing the .vbproj file and removing many lines about hard coded values,
I eventually checked out the project again removed all references to the given DLL and then added it using the GUI.
Lesson learned, don't try to change out one DLL for a newer version without using VB2005 GUI.
The easiest solution will probably be to transfer everything to another project. It will be incredibly time consuming to find where visual studio has left the hard coded path at.
WOOT!!!! Compile the DLL file to a lower version of the .NET framework, and it will fix the problem!!!!
The paths in the project file cannot be the same or the assemblies referenced have a different version.
It might be worth unloading your project and the editing it to inspect where it's looking and for what version.
I had the same problem with an older Visual Studio Project that I opened in Visual Studio 2008. I tried to add new references to the project and got permanent errors that the dll's cannot be found. After the migration of the Project to Visual Studio 2010 I got the following error message when I tried to add a new reference:
'mySample.dll' or one of its dependencies, requires a later version of the .NET Framework than the one specified in the project. You can change ...
After changing the projects .NET Framework to a newer version everything works fine.
Good suggestions in other answers. In my case, it was because the libraries weren't copied (downloaded) successfully: the files existed, but were 0 kB.
Did a clean, which removed all the DLL's and then VS2008 complained it couldn't find the references (Duh!!!) and wouldn't rebuild....luckily I had and old version of the dll's and replaced them in the directory AND THEN did a rebuild to replace them...all references are now OK and we're back to normal....good old VS 2008
I have a C++ DLL project which is created in VS 2010. It is exposed as COM(ATL). I used this dll to another .NET Project as reference. C++ Project linker settings are set as follows:
"Register Output" = Yes
"Per-user Redirection = Yes
I created a build definition to build these two projects in tfs 2010. C++ Project builds fine, but .NET project fails because the output dll of C++ project is not registered. Setting to "Per-User redirection" = false does not work. I also tried using WF activity 'InvokeProecss' to register the c++ dll using Regsrv32/batch file/my own exe etc, but I get exit code of 5. My TFS 2010 is in Windows 2008 Server R2. And I think, it's not running the process as admin.
If I generate a interop dll using tlbimp, and then I refer that interop in my .NET proejct, it works fine(oviously in tfs build, I need to add InvokeProecss to call tlb). But this is not acceptable as our general practice is to refer a COM dll directly from .NET proejct.
Can anybody please help about this?
Is there a way to run the tfs automated build activity 'InvokeProcess' as Administrator without prompting for user name/password?
By default, the TFS Build Service runs as the "Network Service" account which is a relatively low-privilege account. Alternatively, you can configure it to run as any domain account you like. I wouldn't recommend that as a solution to the problem you described, however. I would agree with Hans that, in this case, it would be better to use the type library importer (TlbImp.exe) to "reference" your COM server from your managed assembly.
If the COM object isn't changing, you can just use the type library importer to generate an interop assembly, check that in and reference it from your .NET project. If it is changing, you can add a post-build step to generate the interop assembly rather than using the InvokeProcess activity. As Hans pointed out, you can't actually reference a COM object directly from a managed assembly. Your reference is actually causing an interop assembly to get generated at build time after resolving the reference to the registered COM server.