Here are several good examples of using MemoryStream in C#:
http://www.java2s.com/Code/CSharp/File-Stream/CreateaMemoryStream.htm
This blog is a depository for things I have found regarding VB.NET and C#.NET development (and other things I may need to remember). This blog is primarily for my own reference, but if the information I found is useful to others, then that is great. If others want to contribute with comments or other information, then that is great too.
Wednesday, September 16, 2009
Formatting DateTime in C#
Here is an excellent list of the C# Formatting specifications for the DateTime type. The VB.NET formatting could easily be derived from this post as well:
http://www.csharp-examples.net/string-format-datetime/
http://www.csharp-examples.net/string-format-datetime/
Labels:
DateTime,
Formatting
Monday, September 14, 2009
How to Save a Bitmap as a 1BPP (bitonal) TIFF File in .NET
If you try to use the EncoderValue.CompressionCCITT4 value to save a Bitmap out as a 1 BPP Tiff file, you will get an error "Invalid Parameter Value". It turns out that .NET can't go from an RGB to a Bitonal image with the Save method on a Bitmap (no matter how you set the encoder parameters). The following posting by Michael McCloskey solves the problem:
http://www.codeproject.com/KB/GDI-plus/BitonalImageConverter.aspx?msg=2020403
Easy to use and runs quickly.
http://www.codeproject.com/KB/GDI-plus/BitonalImageConverter.aspx?msg=2020403
Easy to use and runs quickly.
Labels:
TIFF
Thursday, September 3, 2009
My Trials and Tribulations getting a WCF Service running on 64 bit Windows Server 2008 with 32 bit Native Dlls
My WCF Service uses a native DLL written in C++. This native Dll can be 32 bit or 64 bit. The 32 bit version relies on other 3rd party Dlls that are not available in 64 bit. And the 64 bit version is the same thing without the 3rd party dependencies.
1. IIS 7 is easy enough to work in 32 bit or 64 bit mode (on a 64 bit Windows Server 2008 server). By default, the application pool is 64 bit, but you can create another application pool for 32 bit applications or change the default application pool to 32 bit by using the “Enable 32-bit Applications” switch under Set Application Pool Defaults. Then on the Advanced Setting page for your WCF Services Virtual Directory, you can select the Application Pool to use. More Info: http://blogs.msdn.com/rakkimk/archive/2007/11/03/iis7-running-32-bit-and-64-bit-asp-net-versions-at-the-same-time-on-different-worker-processes.aspx
2. The \Windows\System32 directory is for 64 bit files on a 64 Bit OS. And SysWow64 contains the 32 bit files. (Windows on Windows 64 bit). Confusing, but once you know, you know.
3. Getting a 32 bit app using MFC with shared DLLs running on a 64 bit OS can give you a funny error: “The application has failed to start because its side-by-side configuration is incorrect”. The 64 bit OS doesn’t get the standard 32 bit MFC Runtime dlls installed. So you can deliver the 32 bit dependencies or just recompile the DLL using MFC in a Static Library. Easy to fix either way, but the error message is not so obvious. More Info: http://www.eggheadcafe.com/conversation.aspx?messageid=31209382&threadid=31189019
4. The WCF Service always runs fine on the development machine. Deploying it to a real IIS server then has various difficulties to overcome. Mostly, the problem is with security and permissions. If you get: “The caller was not authenticated by the service.” You can possibly just change the binding from wsHttpBinding to basicHttpBinding in the web.config file. Here is more discussion on the issue: http://stackoverflow.com/questions/284538/wcf-error-the-caller-was-not-authenticated-by-the-service
1. IIS 7 is easy enough to work in 32 bit or 64 bit mode (on a 64 bit Windows Server 2008 server). By default, the application pool is 64 bit, but you can create another application pool for 32 bit applications or change the default application pool to 32 bit by using the “Enable 32-bit Applications” switch under Set Application Pool Defaults. Then on the Advanced Setting page for your WCF Services Virtual Directory, you can select the Application Pool to use. More Info: http://blogs.msdn.com/rakkimk/archive/2007/11/03/iis7-running-32-bit-and-64-bit-asp-net-versions-at-the-same-time-on-different-worker-processes.aspx
2. The \Windows\System32 directory is for 64 bit files on a 64 Bit OS. And SysWow64 contains the 32 bit files. (Windows on Windows 64 bit). Confusing, but once you know, you know.
3. Getting a 32 bit app using MFC with shared DLLs running on a 64 bit OS can give you a funny error: “The application has failed to start because its side-by-side configuration is incorrect”. The 64 bit OS doesn’t get the standard 32 bit MFC Runtime dlls installed. So you can deliver the 32 bit dependencies or just recompile the DLL using MFC in a Static Library. Easy to fix either way, but the error message is not so obvious. More Info: http://www.eggheadcafe.com/conversation.aspx?messageid=31209382&threadid=31189019
4. The WCF Service always runs fine on the development machine. Deploying it to a real IIS server then has various difficulties to overcome. Mostly, the problem is with security and permissions. If you get: “The caller was not authenticated by the service.” You can possibly just change the binding from wsHttpBinding to basicHttpBinding in the web.config file. Here is more discussion on the issue: http://stackoverflow.com/questions/284538/wcf-error-the-caller-was-not-authenticated-by-the-service
Simple Way to tell if your .NET app is running in 32bit or 64bit Mode
Here is a quick and easy was to tell if your .NET app is running in 32 bit or 64 bit mode:
C#
VB.NET
More information on from:
http://channel9.msdn.com/forums/Coffeehouse/465445-How-can-I-tell-if-my-NET-application-is-running-in-64bit-on-the-64bit-server/
C#
bool is64bit = IntPtr.Size == 8;
VB.NET
Dim is64bit As Boolean = IntPtr.Size = 8
More information on from:
http://channel9.msdn.com/forums/Coffeehouse/465445-How-can-I-tell-if-my-NET-application-is-running-in-64bit-on-the-64bit-server/
Labels:
64bit
Wednesday, September 2, 2009
Problems with Native DLLs, DllImport, and ASP.NET
I have long had a problem when using ASP.NET where my native Dlls can't be found when the .NET Assembly calls a function from the native Dll. The only solution I have been able to find is to put the native DLLs in a directory that is in the system PATH (or in a directory that is already in the PATH like Windows\system32). I have searched the internet many times and finally found a posting that explains why even if there doesn't appear to be a good solution:
http://bytes.com/topic/c-sharp/answers/843777-asp-net-dllimport
Stephen Cheng explains that the .NET assemblies are copied to a ASP.NET temporary directory before they are are run. Since the .NET assemblies really don't know anything about the native .DLLs, the native DLLs don't get copied. When the .NET assembly tries to use a method in the native DLL, it is not there and you get the error message:
"An exception of type 'System.EntryPointNotFoundException' occurred in xxx.DLL but was not handled in user code Additional information: Unable to find an entry point named 'xxxx' in DLL '.\xxx.dll'."
It doesn't matter that the Native dll is in your ASP.NET project's bin directory, because that is not where it is run from.
The solutions given are to use LoadLibrary to get the dll loaded into memory, but you have to know where it is. You can turn the shadowCopyBinAssemblies off in the web.config file, but this has problems. And finally, you can add the location of the native dll to the system PATH.
If any one knows of a better solution, please post a comment.
http://bytes.com/topic/c-sharp/answers/843777-asp-net-dllimport
Stephen Cheng explains that the .NET assemblies are copied to a ASP.NET temporary directory before they are are run. Since the .NET assemblies really don't know anything about the native .DLLs, the native DLLs don't get copied. When the .NET assembly tries to use a method in the native DLL, it is not there and you get the error message:
"An exception of type 'System.EntryPointNotFoundException' occurred in xxx.DLL but was not handled in user code Additional information: Unable to find an entry point named 'xxxx' in DLL '.\xxx.dll'."
It doesn't matter that the Native dll is in your ASP.NET project's bin directory, because that is not where it is run from.
The solutions given are to use LoadLibrary to get the dll loaded into memory, but you have to know where it is. You can turn the shadowCopyBinAssemblies off in the web.config file, but this has problems. And finally, you can add the location of the native dll to the system PATH.
If any one knows of a better solution, please post a comment.
Labels:
ASP.NET,
DllImport,
Native DLL
Subscribe to:
Posts (Atom)