I need to convert all types of audio formats to the mp3.
I think I need to add the refrence of the dll (lame_enc.dll) into my .net application.
When I try to add the DLL reference to my project, I get an error: "A reference to C:\Lame_Enc.dll could not be added. Please make sure this file is accessible and that it is a valid assembly or COM component"
Is there any other solution that I can convert all types of audio formats to the mp3 and also I need to convert all types of video formats to the flv.
Many thanks for your consideration.
Why reinvent the wheel? Here
http://www.codeproject.com/KB/audio-video/MP3Compressor.aspx
you find a .NET wrapper library for lame_enc.dll. It is written in C#, but usage from VB.NET should be no problem.
By the way, if you want to use native DLLs (no COM, no .NET) from a VB.NET program, you don't have to add a reference to that DLL, you just have to copy that DLL into your working directory of your VB.NET program and use PInvoke. Read this tutorial (C# only, sorry)
http://msdn.microsoft.com/en-us/library/aa288468%28v=vs.71%29.aspx
to learn more about it.
Related
I need to read\write tga files from vb,
I found TargaImage.dll, nice lib but it allows only read tga.
I found FreeImage, tryed to import it in vb, but it says:
FreeImage.dll could not be added. Please make sure that the file is accessible, and that it is a valid assembly or COM component.
I think I have to use , but absolutly dont know anything.
help plz:)
From looking at the way the distribution works, you have two options:
First, you could call the functions in the DLL directly using <DllImport> attributes. This is going to require a lot of learning of how to make calls to unmanaged DLLs, passing the right values, etc. Which is why I suggest the second option.
The second option is, you can use the .NET Wrapper project that is included in the distribution. If you're using a version of Visual Studio that supports multiple programming languages, just add the wrapper project to your solution and reference the wrapper project from the project that needs to use it.
If you're using Visual Studio Express, you won't be able to add a C# project to a VB solution. I'd suggest downloading C# Express, compiling the wrapper project, and then adding the compiled DLL to your VB.Net project.
I am writing a dll in native code (C++) that is to be consumed by other native C++ applications.
One of the tasks of the dll is to perform XML file operations. C++ has poor support in dealing with XML files, e.g searching, writing, reading, as far as I know.
So, I am thinking if I can compile my dll code in clr:mixed mode and use the .NET XML assembly to do the XML related stuff. However, I still want my dll to be consumed by native C++ applications without any added hassles.
Will this approach work ? Any caveats to this ? Btw, is there any other XML library for C++ besides XMLlite ?
so my question is relatively simple, can I create VB6 application that references a class in a dll, and then substitute that dll for another at runtime?
Now my intial guess is... no chance in VB6.
So my thoughts turned to a VB.net interop dll. Could I do it in here, and then call the interop dll from the VB?
Again, my guess would be no.... but I'd be happy if someone knew differently.
The only thing that I think would actually work would be DI in .Net, but I'm limited to .net 2, or 3.5 at a big push, so I dont know if that is possible.
So for the background....
I have a dll that a specific site uses, but we dont want to ship that out to everyone. Instead, we want to build a clone dll which just has the interfaces setup so that the VB6 build will complete.
When it gets to the site that needs it, they want to replace the dummy dll, and drop in their version instead.
Note: We do use RegFreeCOM when its gets installed, so I do have the manifest files that I could play around with if needed.
Any ideas would be much appreciated.
Nick
Its a COM dll so its not statically linked to the VB6 exe, so long as the clsids and interface ids are the same in the type library for both DLLs, you can swap them around as you see fit. (If its a VB6 dll this is trivial to do with the 'binary compatibility' build option)
You could also use late binding instead and instead of making a reference directly in your VB6 code, you would create an object and then set that object to an instance.
Examples and information:
MVPS
Microsoft
I'm working on some legacy VB5/VB6 code and need to convert a ".bas" file to vb.net.
I found several options
Compile the .bas file into a com dll and then reference and use it in my project. (For this I guess I would need vb5 or vb6 which I don't have at my disposal)
Copy and paste the contents of the file in to a new module in vb.net and then try solving the errors one by one.
The contents of the .bas file reference a particular dll.
The .bas file has mostly declarations consts, types, sub's and functions.
What would be the most elegant way of redoing this in vb.net. Is it as simple as option 2.
EDIT
I used VS2008 express and ran the code through the upgrade wizard it did the necessary conversion. and the .bas file was converted to .vb. I took that file and decided to rewrite other parts of the code, including some redoing of the converted .vb file.
Other questions related to this one are here.
Consider rewriting as an alternative. In my experience, this makes less work in the long run than either relying on an opaque COM library or using the VB6 migration wizard and picking up the pieces it spits out.
Depending on your knowledge of .NET, the rewrite of a single VB6 module shouldn’t take very long. If you are freshly starting with .NET then this may take longer but it will also provide good opportunities to learn .NET.
Microsoft provide guidance on what to do including an app that attempts to convert VB6 code to .NET
This includes both your solutions except 2 is helped by the converter.
It depends on how complex the VB6 code and what it does.
However if you are going to have to support and change the VB6 code it would probably be worth doing the conversion now.
There are a lot of advantages to converting to vb.net -- compatibility with future (and possibly current) systems and maintainability being the most important. The main advantage to leaving it as a dll would be to save development time, but this could backfire if there are future compatibility problems.
If the code is in a VB6 project now, or if it can be added to one, you can open the .vbp project file with vb.net and it will it asks if you would like to automatically convert it to vb.net. It does a pretty good job, exclusive of third party add-ons.
I'm facing problem while reference vb6 dll in .net project. When ever i refer a vb6 dll in .net project the interop dll is created with same version(1.2.0.0). Its creating problem for me as the setup used to deploy the application at client side does not replace the dll if the version is same as before. I want to change the version of the interop dll (created using vb6 dll). I read it cam done using tlbIMP but how to create tlb file for vb6 dll. Or is there is any other way to achieve this.
Thanks
Saurabh
Here's a small batch file we use to create our interop dll so it's strongly named:
sn.exe -i MichiganLTAP.pfx MagicContainerName
tlbimp.exe ourVb6.dll /out:Our.Strongnamed.Interop.dll /asmversion:7.1.0.0 /keycontainer:MagicContainerName /machine:X86 /namespace:Our.Strongnamed /verbose /sysarray
sn.exe -d MagicContainerName
The important switch from your perspective is: /asmversion:7.1.0.0
You should be able to set that to whatever you want. Check out the MSDN Library page for more info on the switches available.
It makes very little sense to make the version number of the interop library different from the version number of the type library that was created by VB6. There is a one-to-one mapping between what's in the interop library vs the code you wrote in VB6. The interop library simply contains IL declarations for the VB6 COM interfaces, there is no actual code. The CLR uses it to quickly generate the RCW for the interface.
Change the type library version number in VB6 with Project + Properties, Make tab, Version number. Major and minor is what counts. Do this only when you make a change in the publicly visible VB6 classes. Doing so is required btw, it avoids DLL Hell.