I use Visual C# 2008 and want to write AVI file from bmp sequences.
I found AForge.Video.VWF but it's just for "vmw3" or "DIB " codecs and I want to use AForge.Video.FFMPEG but it got error.
For example I just code :
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using AForge.Video.FFMPEG;
namespace ConsoleApplication4
{
class Program
{
static void Main(string[] args)
{
VideoFileWriter vfw = new VideoFileWriter();
}
}
}
But I got this filenotfoundexception
{"The specified module could not be found. (Exception from HRESULT: 0x8007007E)":null}
In order to use AForge.Video.FFMPEG correctly, you have to be sure to include the FFmpeg dll's into your output folder. The easiest way is to add them into your VS project, go on their properties and set the Copy to Output Directory option to "Always".
The FFmpeg binaries used by AForge can be found on the AForge.NET's external folder, typically in C:\Program Files (x86)\AForge.NET\Framework\Externals\ffmpeg\bin
Not sure if this is still relevant, but downloading Accord.Video.FFMPEG will take care of this for you, just remember to build explicitly to x86
using Accord.Video.FFMPEG;
it's happened because this AForge.Video.FFMPEG.DLL depend upon another dlls. copy all that dll into output folder.
Related
I'm using SSIS and a c# script task. I want to zip multiple csv files without using any 3rd party applications.
This is my code:
#region Namespaces
using System;
using System.Data;
using Microsoft.SqlServer.Dts.Runtime;
using System.Windows.Forms;
using System.IO.Compression;
#endregion
public void Main()
{
{
string startPath = #"\\xxxxxxxxxxxxxxxxxxxxxx\*.csv";
string zipPath = #"\\xxxxxxxxxxxxxxxxxxxxx\result.zip";
ZipFile.CreateFromDirectory(startPath, zipPath);
}
Dts.TaskResult = (int)ScriptResults.Success;
}
However, ZipFileis being underlines and the error:
the name zipfile does not exist in the current context
I am basing it from this Microsoft example:
https://learn.microsoft.com/en-us/dotnet/standard/io/how-to-compress-and-extract-files
The above article states: If you get the build error "The name 'ZipFile' does not exist in the current context," add a reference to the System.IO.Compression.FileSystem assembly to your project. But there is no System.IO.Compression.FileSystem within the script editor in SSIS?
I believe you dont have the reference to the System.IO.Compression set up correctly.
Just using the statement, using System.IO.Compression; does not make System.IO.Compression available, you have to reference the correct dll to your project as well. System.IO.Compression is a .Net assembly that comes with .Net.
Right-click on the References Folder within your Project (or directly on your Project) in the Solution Explorer.
Choose Add Reference
Under the Assemblies or .NET tab, look until you find System.IO.Compression.FileSystem.dll.
Select it and Click OK.
If you are using core, you might need to install it from nuget package.
I'm trying to play a wav file from a .NET Core console application (No, I'm not using the console beep. Weird requirements, I know.). I figured I could do that using OpenAL. I'm able to read the file in fine, but then when I try to play it, it fails on the first line:
int handle = AL.GenBuffer();
I get the exception: InvalidOperationException: Could not load openal32.dll. I'm using the OpenTK.NETCore NuGet package. Am I missing something?
I figured it out. It turns out the OpenTK.NETCore package doesn't come with OpenAL, just the SDK. Instead, it looks for it already installed on the machine. I used the installer, and imagine I'll need to install it on every machine that uses my application
Not using OpenAL, but an alternative solution to play wav files in a console application can be found here:
Playing sounds on Console - C#
After adding the sound file to your solution the suggested code in the link is:
using System.Reflection;
using System.IO;
using System.Resources;
using System.Media;
using System.Diagnostics;
namespace Yournamespace
{
public partial class Form2 : Form
{
public Form2()
{
InitializeComponent();
}
private void Form2_Load(object sender, EventArgs e)
{
Assembly assembly;
Stream soundStream;
SoundPlayer sp;
assembly = Assembly.GetExecutingAssembly();
sp = new SoundPlayer(assembly.GetManifestResourceStream
("Yournamespace.Dreamer.wav"));
sp.Play();
}
}
}
I just got C# working on Ubutnu. It's all good. But now I want MySql too. I installed the gacutil, and downloaded the connector, and I ran the gacutil, which it seemed like it worked.
I'm using Geany as my ide for now. It's free and already installed, and it worked great; until I tried to add using MySql.Data; I've read through all the stackoverflow posts for MySql.Data: they all state that I need to add an entry to my reference list in the VS project. Well, I don't have a reference list, nor a project. My 'project' directory only contains two(2) files: Test.cs, and Test.exe. MySql.Data is registered in the gac! Arg! Please, how do I get this working?!?!?
Running the gacutil:
dysmondad#Julep:/etc/mono/mysql/v4.5$ sudo gacutil -i MySql.Data.dll
Installed MySql.Data.dll into the gac (/usr/lib/mono/gac)
Complete source code for testing Mono install.
using System;
using System.Collections;
using System.Collections.Generic;
using MySql.Data; // <- this isn't recognized.
public class Test
{
static public void Main ()
{
List<int> integers = new List<int>();
integers.Add(7);
integers.Add(14);
integers.Add(21);
foreach( int i in integers )
{
Console.WriteLine(i);
}
}
}
UPDATE-1: Just found this on the MySql support page._______
You are now ready to compile your application. You must ensure that when you compile your application you include the Connector/Net component using the -r: command-line option. For example:
shell> gmcs -r:System.dll -r:System.Data.dll -r:MySql.Data.dll HelloWorld.cs
But...these don't work
-r:MySql.Data.dll
--nor--
-r:MySql.Data
UPDATE-2: I just discovered that if I use the -r option, and include the full path and name of the dll (even though it was registered with the gacutil) that seems to satisfy the compiler. So now my question is: how to get it to work with just the package name and not have to specify the full path?
I'm used C# -some- but not recently.
I've got this header from some code, and it calls a custom non-system library, (Dynastream.Fit, at the bottom), but I need to know how to tell the program where it resides so it can compile. Pretty sure the library is in the SDK I downloaded, just need to find it. This is the FitSDK from ANT+.
using System;
using System.Collections.Generic;
using System.Text;
using System.IO;
using System.Diagnostics;
using Dynastream.Fit;
You need to add the dll of Dynastream.Fit to your project Reference folder by right clicking the reference folder -> add reference -> Browse -> choose the dll; unless you have already installed the assembly in GAC.
This problem has been causing me a headache for a few days, and I cannot find a reason for it. I'm pretty sure this is an environmental issue particular to my machine, but still its causing me problems with testing.
I'm creating a DLL in C# using Visual Studio 2010 Professional. Version one is below;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Windows.Forms;
using System.Runtime.InteropServices;
namespace TestCOM
{
[ClassInterface(ClassInterfaceType.AutoDual)]
[System.Runtime.InteropServices.ComVisible(true)]
[System.Runtime.InteropServices.ProgId("TestCOM.Class1")]
[System.Runtime.InteropServices.Guid("803A1B2F-1CDA-4571-9084-87500388693B")]
public class Class1
{
public void showMessage()
{
MessageBox.Show("Hello from TextCom");
}
}
}
This assembly compiles fine, and everything is good. I run the following script to register it as a COM object (first for 32-bit, then for 64-bit);
C:\Windows\Microsoft.NET\Framework\v4.0.30319\regasm.exe TestCOM.dll /codebase /nologo /tlb:TestCOM32.tlb
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\regasm.exe TestCOM.dll /codebase /nologo /tlb:TestCOM64.tlb
And then use the following script to test it;
dim tc
set tc = CreateObject("TestCOM.Class1")
tc.showMessage()
I use csript to test the script, so I can control which bit depth it uses - I test it once with 32-bit and once with 64-bit. So far everything is good.
Now, when I modify the original assembly to add a function, as follows
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Windows.Forms;
using System.Runtime.InteropServices;
namespace TestCOM
{
[ClassInterface(ClassInterfaceType.AutoDual)]
[System.Runtime.InteropServices.ComVisible(true)]
[System.Runtime.InteropServices.ProgId("TestCOM.Class1")]
[System.Runtime.InteropServices.Guid("803A1B2F-1CDA-4571-9084-87500388693B")]
public class Class1
{
public void showMessage()
{
MessageBox.Show("Hello from TextCom");
}
public void HelloWorld()
{
MessageBox.Show("Hello World!!");
}
}
}
Before the modification, I unregistered the library using "regasm /unregister" and it reported all types unregistered successfully.
When i register the library, now with changes, the original test script works perfectly. If I extend the test script to call the new HelloWorld function;
In 32-bit scripts, it works perfectly.
In 64-bit scripts, it complains that no such function exists for the TestCOM.Class1 object
I've tried this every which way I can, but I cannot identify why the new function is available to the 32-bit callers, but not the 64-bit calls.
What am I doing wrong ? is there a cache somewhere for the 64-bit stuff I'm not aware of, or a registry setting that needs changed?
To be clear;
1. Build assembly
2. Register using regasm, once for 32 and once for 64
3. Test using script - everything works
4. Unregister library
5. Make modifications, rebuild
6. Register as per Step 2
7. Tests work in 32-bit, but not 64. Wtf ?
Clearly you are suffering from DLL Hell, always around with COM, it is loading an old version of your DLL. Your GAC could have gotten polluted by earlier experiments, it will always find the GACed version first. You are making it worse by specifying the [Guid], making your new class look the same as the old one, even though it is not identical. Preventing COM from telling you that it cannot find the new version of the class.
The most reliable, although noisy, way to see where the DLL came from is by using SysInterals' ProcMon utility. You'll see it reading the registry key and loading the DLL. You can see what directory it came from. Make sure it is not the GAC, remove it with gacutil /u if that's the case, and make sure that you got it rebuilt by checking the timestamp on the file.