I have a task to extract files from zip archive. Unfortunately, as I found from another question here, windows explorer in win10 still uses cp866 to encode filenames inside of archive file. .NET Core doesn't support this codepage, so extracting the archive results in non-readable symbols. Aspose.Zip faced me with the exactly same problem. Is there a way to solve this in .net core 3.1 stack? Maybe in .net 5?
By default, both .NET Core 3.1 and .NET 5+ includes limited set of encodings out-of-the-box. But, you can fix this by only pair rows of code: you just need to register a custom encoding provider (see https://learn.microsoft.com/en-us/dotnet/api/system.text.codepagesencodingprovider?view=net-5.0) and voila - get needed encoding by its number:
Encoding.RegisterProvider(CodePagesEncodingProvider.Instance);
var encoding = Encoding.GetEncoding(866);
Then you can easily extract files from a zip, archived in Win Explorer, without non-ascii symbols problem.
Related
I've created a managed C++ log parser application using C++ vectors and Winforms. I want to add multithreading and Boost seemed like a better option than Winforms BackgroundWorker because I want to be able to execute my existing C++ function with each thread. I installed Boost multiple times following multiple different tutorials (lastly this one: https://levelup.gitconnected.com/the-definite-guide-on-compiling-and-linking-boost-c-libraries-for-visual-studio-projects-c79464d7282d) and I still have the same issue when I try to #include <boost/thread.hpp>
Error LNK1104 cannot open file 'libboost_thread-vc143-mt-x64-1_78.lib'
I don't know why it's looking for this library when I have Boost 1_79 installed not 1_78. My .lib file also has "mt-gd-x64" not just "mt-x64". I've already specified the correct file path to the library in Project->Properties->Linker->General->Additional Library Directories. I've also tried installing Boost via Visual Studio 2022 NuGet Package Manager. The lib file in that folder is also slightly off. "vc120" instead of "vc143". I've even tried changing the .lib file name to match the file name in the linker error exactly but when I do that I get more errors like LNK1104 cannot open file 'libboost_chrono-vc143-mt-x64-1_78.lib'
Do I just need to delete all my Boost files and download version 1_78 and try again? Why is Visual Studio looking for the wrong file name when it compiles? Is my #include statement wrong?
I ended up solving this problem by downloading boost 1_78, building it, and specifying that folder instead or the 1_79 folder. If anyone might know why the program was looking for 1_78 instead of 1_79 feel free to respond Also big thanks to George Gkasdrogkas who wrote the tutorial that worked best for me on how to install Boost. Tutorial is linked in the question :)
I'm trying to read Excel file with GoLang (even not .xlsx) and by using several libraries can't have success in it. The libraries just crashes on OpenFile stage with such error:
zip: not a valid zip file
Libraries which I tried to use:
https://github.com/tealeg/xlsx
https://github.com/tealeg/xlsx2csv/
There were some others too, but they were crashed during
go get Name-of-Lib because of some Dll problems.
Any ideas? Is it because I'm trying to do in under MacOS or by some other reason?
The libraries you are trying to use 1, 2 support only newest Microsoft Excel format which is actually a zip with xml documents. Therefore you get error: zip: not a valid zip file. Those can be used on your MacOS, but first you need to convert the old XLS files into XLSX files. You should be able to convert them with LibreOffice in headless mode like described other question, you can run a process from your code.
The other libraries are failing with "dll" errors because they must be linked against Windows Dynamic Link Libraries. As so, they are not usable on your MacOS.
I've inherited a legacy .Net 3.5 VB app to support from a client and they'd like to make some small data changes. Before we begin I think it's important to note that I am running Windows 7 64 bit, and VS 2013 Ultimate R2.
While making my first changes to the project, I noticed their datasets use a custom tool AGDataSetGenerator (written by Shawn Wildermuth in 2004). I did a lot of poking around on how to register custom tools. I went over to http://www.codeproject.com/Articles/8582/Inherit-from-ADO-NET-DataSet-to-create-your-own-bu and got the source code of the tool, inside the project there are a couple of utility files that you need to run in order to register the tool. Remember this was made in 2004 so things were a little different back then.
I modified the Reg.cmd file to point to v2.0.50727 since my project is running .Net 3.5 and .Net 3.0 and 3.5 are both just minor updates from .Net 2.0 and not completely new .net versions. Also I noticed that there is both a Framework and a Framework64 folder with the C:\Windows\Microsoft.Net folder, so I added both locations to my .cmd file in hopes to cover all of my bases. Code Below
Reg.cmd - Original
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\regasm /codebase /verbose F:\AGDataSetGenerator.dll`
Reg.cmd - My Modified Version
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\regasm /codebase /verbose F:\AGDataSetGenerator.dll
C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\regasm /codebase /verbose F:\AGDataSetGenerator.dll
Then it was on to the.reg file.
Upon opening the file my first thought was, cool, I can just switch the version from 7.1 to 12.0 and away we go. Not the case. After quite a bit of googling I found the first line registers the tool for VB.Net, and the second registry entry registers the tool for C#, so for me I only need the first line, also VS now a days registers to a new location HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\VisualStudio\ for 64 bit specific registers. So in hopes to cover my bases once again, I tried including both 32 bit and 64 bit locations. I even threw in a more global register for both 32 and 64 bit that in hopes that would point visual studio to the generator entry, unfortunately I'm a bit out of my wheelhouse here so I was pretty much grabbing at straws.
BSDataSetGenerators.reg - Original
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.1\Generators\{164B10B9-B200-11D0-8C61-00A0C91E29D5}\AGDataSetGenerator]
#="ADOGuy DataSet Generator"
"CLSID"="{87BF1B1C-E1DF-4f24-A07E-2BD9B8CAD316}"
"GeneratesDesignTimeSource"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.1\Generators\{FAE04EC1-301F-11d3-BF4B-00C04F79EFBC}\AGDataSetGenerator]
#="ADOGuy DataSet Generator"
"CLSID"="{3C13044D-394D-45cd-89FF-51C885BFBCD9}"
"GeneratesDesignTimeSource"=dword:00000001
BSDataSetGenerators.reg - My Modified Version
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\12.0\CLSID\{87BF1B1C-E1DF-4f24-A07E-2BD9B8CAD316}]
#="AGDataSetGenerator"
"InprocServer32"="C:\\WINDOWS\\system32\\mscoree.dll"
"Class"="BottomLine.Generators.VBNETAGDataSetGenerator"
"Assembly"="AGDataSetGenerator, Version=1.0.0.0, Culture=neutral, PublicKeyToken=35e4ca7ea38d2508"
"ThreadingModel"="Both"
[HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\VisualStudio\12.0\CLSID\{87BF1B1C-E1DF-4f24-A07E-2BD9B8CAD316}]
#="AGDataSetGenerator"
"InprocServer32"="C:\\WINDOWS\\system32\\mscoree.dll"
"Class"="BottomLine.Generators.VBNETAGDataSetGenerator"
"Assembly"="AGDataSetGenerator, Version=1.0.0.0, Culture=neutral, PublicKeyToken=35e4ca7ea38d2508"
"ThreadingModel"="Both"
[HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\12.0\Generators\{164B10B9-B200-11D0-8C61-00A0C91E29D5}\AGDataSetGenerator]
#="AGDataSetGenerator"
"CLSID"="{87BF1B1C-E1DF-4f24-A07E-2BD9B8CAD316}"
"GeneratesDesignTimeSource"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\12.0\Generators\{164B10B9-B200-11D0-8C61-00A0C91E29D5}\AGDataSetGenerator]
#="AGDataSetGenerator"
"CLSID"="{87BF1B1C-E1DF-4f24-A07E-2BD9B8CAD316}"
"GeneratesDesignTimeSource"=dword:00000001
Regardless of everything I've tried. When I right-click a dataset and try to run custom tool. BAM! I get the following:
If anyone can get this working in similar settings to my own, I'd love to know how you did it.
I'm very much the type of person that find's it very hard to take NO for an answer when it comes to technology. Unfortunately the answer here is simply just "No". The custom tool is very much outdated and to get it to work in VS 2013 just isn't feasible (I still can't bring myself to say impossible).
I'm writing this answer because I have a workaround that I suggest anyone in the same situation use straight out of the gate instead of trying to get that old tool to work. As a workaround, I created a new data project in .Net 3.5 and used entity framework to bring in just the models I needed to update. I generated my models from database and then went to the .aspx code behinds and replaced references to the outdated generated datasets. It took some refactoring but using EF instead of those ancient generated datasets cut the code by about 40%. Win Win in my opinion. Hope this helps someone else in the future.
According to the old .reg reference to VS 7.1, that means it was built to work in VS 2003. I know that VS plugin coding changed a lot in VS 2010 and later editions. So, it is possible this plugin may only work in VS 2003... possibly all the way up to VS 2008. But, it may need to be re-written to work in anything later.
Hopefully you have MSDN or know someone who does. I would spin up a VM, install VS 2003 (or you could try up to VS 2008), and install this plugin using the original .reg/.cmd.
I am pretty experienced writing my own code, but not in C++. I am used to adding .NET assembly references, and I want to get into using C++.
I downloaded a VC++ 6 project presenting a graph algorithm, opened it in Visual Studio 2010 Ultimate and downloaded the required libraries (LEDA .NET assemblies) however, they came with both DLLs and LIB so I thought I would have no problems with the .NET and C++ connection. Also, the LEDA project comes with C++ style .header files, and static libraries, yet frustration persists.
I put my LEDA header files in a directory visible to the project, since I can "Go to definition" of all the custom LEDA data types and see where they are defined in the LEDA include files.
But, I can not compile/link these data types in. The VS finds their very existence repulsive, and refuses to acknowledge they could possibly be found in leda.lib.
Steps I have already taken:
Added additional /LIBPATH path under Properties ->Linker->General
Added explicit lib references under Properties->Linker->Input
Added all the paths containing LEDA header files and libraries to every path location I can find, like include path, reference path, library path.
Copied the DLLs and LIBs to the release folder as well as the base folder of the project.
Added a #pragma comment( lib, "leda" )
Still no joy.
It's quite bad since none of the custom typedefs are recognised the errors balloon to 646 errors.
If anyone is kind enough to offer assistance, thank you.
I can't guarantee this will work but try the following steps (therefore using it's default predefined paths instead of setting your own ones) :
1) Copy *.dll into Windows/System32 or / and (there is some confusion about x64 and x32 default checking in my head :)) Windows/SysWOW64.
2) Copy *.h files into x:\PathToVC2010\include\
3) Copy *.lib files into x:\PathToVC2010\lib\
I'm porting an OpenCV 2.2 app from Unix (that works) onto Windows 7 64-bit and I receive the following exception when cv::imwrite is called
"OpenCV Error: Unspecified error (could not find a writer for the specified extension) in unknown function, file highgui\src\loadsave.cpp"
The original unix app works fine on my Mac and Linux boxes.
Does anyone know what library or compiler config I could be missing that makes this work on Windows?
UPDATE:
I did the following things to get OpenCV running:
Downloaded the binaries for v2.2 from the OpenCV site for windows. I'm using 2.2 because the original app uses it and I don't want to complicate my build at this stage.
I am trying to imwrite to a .png file. I looked at the OpenCV code and noticed the necessity for external libs for Encoders such as Pngs or jpegs, so I tried writing to .ppm, .bmp which seems not to require deps, but I get the identical error.
An example of my usage is cv::imwrite("out.png", cv_scaled); where cv_scaled is of type cv::Mat with format CV_32FC1
Please remember the identical code works fine in unix
The fact .bmp or .ppm doesn't work this raises more questions:
Why don't these very simple formats work?
Is there a way to see a list of installed Encoders programmatically?
Thanks again for your kind assistance in helping me debug this problem.
Your current installation of OpenCV doesn't support the file format you are trying to create on disk.
Check if the extension of the file is right. If it is, you'll have to recompile OpenCV and add support to this format and possibly install the libraries you are missing.
That's all that can be said without more information.
EDIT:
As I have also failed building an application that uses the C++ interface of OpenCV (v2.3 on VS2005) I ended up using the following workaround: convert the C++ types to the C types when necessary.
To convert from IplImage* to cv::Mat is pretty straight forward:
IplImage* ipl_img = cvLoadImage("test.jpg", CV_LOAD_IMAGE_UNCHANGED);
Mat mat_img(ipl_img);
imshow("window", mat_img);
The conversion cv::Mat to IplImage* is not so obvious, but it's also simple, and the trick is to use a IplImage instead of a IplImage*:
IplImage ipl_from_mat((IplImage)mat_img);
cvNamedWindow("window", CV_WINDOW_AUTOSIZE);
// and then pass the memory address of the variable when you need it as IplImage*
cvShowImage("window", &ipl_from_mat);
Try
cvSaveImage("test.jpg", &(IplImage(image)));
instead of
imwrite("test.jpg", image);
This is a known bug in the version you are using.
From the OpenCV 2.2 API:
The function imwrite saves the image to the specified file. The image format is chosen based on the filename extension, see imread for the list of extensions. Only 8-bit (or 16-bit in the case of PNG, JPEG 2000 and TIFF) single-channel or 3-channel (with ‘BGR’ channel order) images can be saved using this function. If the format, depth or channel order is different, use Mat::convertTo , and cvtColor to convert it before saving, or use the universal XML I/O functions to save the image to XML or YAML format.
You might have more luck converting your file to 8 or 16 bits before saving.
However, even with single channel 8 bit files I have had unknown extension errors trying to save jpg or png files but found that bmp works.