VS 08 Express to Classic ASP - vb.net

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.

Related

VB.NET - How to ad a My extension

I am trying to access the My.Computer object in a class library project (Visual Studio CE). I know people say that I should find in Project Properties a "My Extensions" option - but it's just not there.
Microsoft site says the exact same thing but I just can't find that option.
To access the My Extensions page, double-click My Project for your project node in Solution Explorer. When the Project Designer appears, click the My Extensions tab.
https://learn.microsoft.com/en-us/visualstudio/ide/reference/my-extensions-page-project-designer-visual-basic?view=vs-2017
Besides that, Microsoft says the My.Computer should be available in Class Library project. Well, it's not. As a matter of fact My is totally empty.
https://learn.microsoft.com/en-us/dotnet/visual-basic/developing-apps/development-with-my/how-my-depends-on-project-type
LE:
Visual Studio Community 2017 15.8.1
.NET Framework 4.6.01055
Class Library type: .NET Standard
ANSWER: .NET Standard Class Library does not have My extensions. Use .NET Framework Class Library when creating the project to be able to access My objects.

VB6 calling VB.NET calling third party COM dll error

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.

Where are the .net core dlls stored on my computer?

I cannot find the dlls. Visual Studio does not tell you where they are stored. I want to load them into .net Reflector.
I know this is an old question, but if you're looking for these then check out the following location...
C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App
Under there should be versions of .NET Core, and these are the runtime assemblies you'll need to load in Refelctor to see the source code.
Note - if you use an assembly reference from within Visual Studio (by maybe clicking F12 on a .NET Core datatype or interface), that will show the reference assembly and not the implementation assembly.
As an example, hitting F12 on ControllerBase gives me this...
C:\Program Files\dotnet\packs\Microsoft.AspNetCore.App.Ref\3.1.0\ref\netcoreapp3.1\
Microsoft.AspNetCore.Mvc.Core.dll
This is not the runtime assembly you need when using Reflector. GitHub is all fair and good for finding source code to one method, but you can't beat Reflector when you want to move between different classes in different files so as to work through an implementation pathway.
Hope this helps!
You can set them up I properties. They are still in the bin folder once the code is compiled. Although if you are planning on using the dll directly you can publish then first

COM DLL registration failed with TFS 2010

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.

Using CLS instead of dll in Visual Basic

I've seen in several places that you should create a CLS file in Visual Studio 2010 instead of a dll file. I see how a windows application can get use a CLS file, but I am writing an extension for a program that is looking for dll files. Is it possible to create a dll in Visual Studio 2010. If not, is there a difference between using a dll vs. a cls as an extension
I only know the .cls extension as a VB6 class type source file and have heard of compiled java cls files. For interest sake, where have you seen that you should create CLS files in VS2010 instead of dlls?
Of course it's possible to create a dll in Visual Studio 2010. As in previous versions, dlls are Class Library assemblies. When you compile a Class Library project, you get a dll.You can also still check an option to 'Register for COM interop', which means you'd be able to use your dll with older applications built in VB6 for example, provided the interops are generated correctly.