Does anyone know if there exist a dll in windows (2003 server) which I can call to calculate a MD5/SHA1 hash for a string?
I've written a .dll in C# that do this but I'm not allowed to use this because of company regulations for our servers.
/Ausgar
If you do have a .NET 2.0 installed (which I think you do), then yes, there is one.
It's accessible via COM as System.Security.Cryptography.MD5CryptoServiceProvider and System.Security.Cryptography.HMACSHA1, respectively.
It's no use to implent it in C# as C# relies on .NET and .NET has implemented it for you already.
P.S. If there is no .NET on your system or you reluct at using .NET/COM for some reason, then there is sample using Microsoft Crypto API.
Have you tried openSSL?
(e.g. there are precompiled libeay32.dll and libssl32.dll files for windows, I'm not sure where the docs are that describe the DLL functions available in each of those, though)
Related
I had faced some strange behavior while using "broadFileSystemAccess" capability during my app development, i.e.
I'm using above mentioned capability to access entire file system and my app's both min and max version I kept ver 17134 (RS4), and below API's are throwing access denied exceptions in spite of declaring broadFileSystemAccess capability.
The API's are listed below:
ZipFile.CreateFromDirectory - From System.IO namespace
Refer https://github.com/siddhu10/Zipping.git for a sample example which fails for above API.
DownloadFileAsync from FluentFTP - 3rd party lib from nuget
Refer https://github.com/siddhu10/FileTransfer.git for a sample example which fails for above API.
Imp Note: The observation is above API's fail only when min ver is also 17134 (RS4) and higher versions. These API's work when min version is kept 15063 and lower versions.
Kindly help resolving above issues.
The way .NET handles brokered file paths changed in RS3 as part of the .NET Standard work. Prior to RS3, the System.IO types would try to use the WinRT APIs under the covers to access brokered files, which worked as long as the user had granted the app access.
Starting in RS3, the APIs changed to just use the raw Win32 APIs (as part of the standardization effort). There are now Win32 APIs that can access brokered locations, but due to a sequence of unfortunate events these aren't the APIs .NET is using.
As long as your min-ver is less than RS3, you'll get the older behavior (but not full .NET Standard 2.0 support).
As of now, the only way to access brokered locations if your min-ver is RS3 or higher is via WinRT APIs or Win32 FromApp APIs. And since broadFilesystemAccess is in RS4, I'm afraid you can't use it with the System.IO APIs.
If you need to use .NET APIs then you will need to set the minver to RS2 or lower and then ask the user to pick a folder with the FolderPicker. You can then use the FutureAccessList to ensure you have ongoing access to the location.
The problem is that the broadFileSystemAccess capability applies only to the new Windows.Storage APIs in UWP. The classic File IO API you are using are not allowed to access.
You can verify this in the docs. This means you will either have to replace the code with alternatives that use the new APIs or copy the files you need to use to a location that is accessible to the classic APIs like ApplicationData.Current.LocalFolder.
I guess the conclusion here is that .Net Standard file access model (System.IO namespace) is completely broken for UWP apps and there is absolutely no way to make it work. I hoped that broadFileSystemAccess would fix that, unfortunately that is not the case. Hope this will be fixed soon.
I have a 3rd party legacy app that requires a VB6 Active X EXE library interface. I am looking to update the VB6 Active X EXE library to a currently supported language. As the legacy host application is from a 3rd party I do not have the ability to change the host API to use an interface other than ActiveX EXE. Is there any currently supported Microsoft language i.e., x86 C++, C++/CLI, C# or VB.NET that can create the equivalent of an ActiveX EXE interface?
I suspect the answer is no but am looking for a definitive response saying so. That any legacy host application using ActiveX EXE library must be itself be modified to allow the use of supported languages and tools. Basically confirming that effectively ActiveX EXE is now an unsupported API interface.
I've already looked at this similar question and from it one could deduce that the answer is no but there is no definitive response. I've also looked at this Microsoft Tutorial and from what I can tell it talks about updating the host application which isn't an option in this case. The tutorial talks about switching to an ActiveX DLL but my understanding is that this would require a change to the 3rd party host application. Again that is not an option in my case. I need something that looks like an ActiveX EXE library to the host.
If you are sure that an ActiveX Exe is required, have you considered just using VB6 to create the that as a thin shim and then have it delegate all implementation to a .NET assembly? You probably would never need to recompile the Exe again, unless the 3rd party vendor is still expanding their interface.
If you post some more information about the VB6 Active X EXE library interface, I might be able to refine this solution with specific code samples. Presumably your Active X Exe must implement a provided interface?
I have a "proof of concept" piece of work that crosses over into some unfamiliar territory. I have some experience on J2EE technologies. I'm tasked with connecting an EFTPOS machine to an web application. I am planning to use applet to interact with dll. dll will be running on the client side.
I need to interact with one dll from web application. Please provide me any guidance on this, as I am new to it. I tried interacting with dll from standalone java program, but not able to connect from web application. Any sample codes will be very helpful for me.
Yes that is perfectly possible with an applet. I "connected" an electronice signing device before and it was working very well. Depening on what kind of .dll we are talking about here you need to do the following things:
1.) Create a java access layer / interface for your dll, so that you are able to call the dll functions from java. Depending what kind of dll we are talking about there are several possibilities. The base technology is JNI which is however quite cumbersome to use but luckily there are much more convienient ways out there:
use JNA (if it is a C dll)
use Jacob (if it is a COM component)
use bridj (if it is a c++ dll. You may try swig but haven't used that, so can't tell)
2.) Put your dll inside a jar file and distribute it alongside your applet. How this works is quite nicely described in the jacob project which provides an example for that. You can find it in the source package under jacob-1.17_src.zip\jacob-1.17\samples\com\jacob\samples\applet The example describes the JNLP way to access a native library which will work above java version 1.6.0_10. If you have to use a lower version for some reason, it is also possible but is slightly more tricky...
3.) One more side note: Since the latest available java version (1.7.0_51 or 1.6.0_71) due to security, some rules have been added or tightened for java applets. Now you have to sign your applet with an official certificate and set the right attributes/properties in the manifest, jnlp files. But this has been discussed in great detail here so just search for it. I would probably use a slightly older version for development and if that is working, figuring out how to make it work in the latest java version...
4.) Regarding the interaction part there are also several possibilities. Your Java Applet can call jscript methods from the website it is running in (or also the other way around) or the applet directly communicates with your server. You have all possibilities on that front...
Can VS2012 build a proxy in a PCL project to consume a WCF service for SP2010? We add a reference (old school works everywhere else) but once we make calls, for instance GetListsCollectionAsync(), we get all sorts of errors. When we build the proxy, VS gives a warning:
Service proxy generation failed. Proxy requires type 'System.Xml.Linq.XElement' which is not supported in portable libraries
Has anyone successfully subscribed to a SharePoint WCF using a portable class library? The same stuff works fine in .net 4.5 class libraries and in metro libraries. Only portable ones give us this problem. We have win 7 and win 8 devices in the mix - so PCL would be a really good fit.
Got a conclusion here: We found a work around and the statement that this is a bug in VS2012 PCL projects still stands.
We created our proxy in a metro project and simply copied the reference.cs file over into the PCL project. It was a "what the heck - why not" last attempt of sorts, but it actually works. Even better, the calls are awaitable and come with response objects. Awesome!
Cheers,
Gregor
Is there any SDK available to convert MS word and Excel files to PDF ? I wan to do it on Web Server at run time. Im using VS 2010, .Net Framewrok 4.0
I looked into MS interop assembly but then this artical pushed me back http://support.microsoft.com/kb/257757
is there any thirdparty tool/SDK/Service available that will do that at runtime?
Check out iText, there is a Java and C# library however I think the .NET library is not free. http://www.itextpdf.com/
If you are after perfect conversion then there is no real solution available / viable other than somehow involving Office. Plain MS-Interop is a nightmare and very unreliable, but there are good third party solutions available.
Give the Muhimbi PDF Converter Services a look. It installs in your environment as a scalable and robust Windows Service and has specifically been designed for use from server based applications such as ASP.NET.
It comes with a friendly web services based interface that allows it to be used from most modern environments such as Java and .NET. It supports all common as well as some not so common file formats. Watermarking and PDF Security is included as well. If you have SharePoint in your environment then a SharePoint optimised version is available as well.
Disclaimer, I have worked on this product so the usual disclaimers apply. Having said that, it works great.
You can use the Save as function which is already available in Microsoft.Office.Interop
doc.SaveAs(ref FileName, Microsoft.Office.Interop.Word.WdSaveFormat.wdFormatPDF);