I was reading chapter 20 "Automation" of the book by Jeff Prosise "Programming Windows with MFC", 2nd ed. There are instructions on how to create a small automation server with methods long Add(long, long), long Subtract(long, long), and a property double Pi. There's also a script in VBScript to test that server. When I ran that script the message box with error 0x800700c1 was shown.
The problem was with the file \Documents in my system drive (where Windows is installed). The automation server was in one of \Documents and Settings subfolders of the same drive. After deleting \Documents file everything ran fine. I currently don't know which application created that file.
Related
I have a Xamarin iOS application in VisualStudio 2019 on a Windows 10 PC. I build it on the PC, and when possible then right click the project and choose Show IPA File on Build Server, then on my Mac I upload the file to the app store using Transporter. I am encountering these issues:
Whenever I build, the build says it failed with message "There was an error unzipping the file bin\Ad-Hoc\MyApp.app.dSYM.zip: Could not find a part of the path 'C:\MyDirectory\MyApp.iOS\bin\Ad-Hoc\MyAppiOS.app.dSYM'." This has not historically caused any issues - we have still been able to upload the IPA to the app store and deploy our app - but I include it in case it's relevant to the other issues.
Sometimes, my build fails saying it "has been disconnected while waiting a post repsonse to topic xvs/Build/.../execute-task/MyApp.iOS/...Codesign" or "Unable to connect to Mac Server with Address='192.111.111.111' and User='My Username'. The build can't continue without a connection". I'm assuming a wifi issue must cause this, though the machines are all right next to one another and next to my router so seems odd. Occasionally when I try to pair to the Mac, I also get the message "Error, Couldn't connect to com. Please try again. An attempt was made to access a socket in a way forbidden by its access permissions." In any case, makes me wonder if there's any way for me to 1) hardwire the Mac to the PC or 2) build directly on the Mac instead of through VS on the PC, even though I write the code on the PC?
During the build, I periodically get an error "/Users/myUser/Library/Caches/Xamarin/mtbs/builds/MyApp.iOS//bin/Ad-Hoc/MyAppiOS.app: errSecInternalComponent MyApp.iOS C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets 2003". If I lock all keychains on the Mac this goes away on the next build, but then it reappears a few builds later.
Once the build finishes with just the .dSym.zip error, most of the time, the "Show IPA File on Build Server" option still does NOT show up (not greyed out - it is not present in the menu at all) when I right click the iOS project. To get around this, I have been copying the file over to the Mac via S3. I'm wondering why the option doesn't show up, and if there's a way to just find the built file on the Mac rather than copying it over from Windows?
I then use Transporter on the Mac to upload the IPA file to the Apple Store. It always is able to read the version information and says the file is Delivered. However, often I then get an email from Apple saying the build failed because "ITMS-90688: This IPA is invalid - While unzipping the IPA we received the error message [ End-of-central-directory signature not found. Either this file is not a zipfile, or it constitutes one disk of a multi-part archive. In the latter case the central directory and zipfile comment will be found on the last disk(s) of this archive. unzip: cannot find zipfile directory in one of MyAppiOS.ipa or MyAppiOS.ipa.zip, and cannot find MyAppiOS.ipa.ZIP, period. ] Verify that the IPA can be unzipped before reattempting your upload.".
In response to that error, I've tried to unzip the IPA file and I find that on the PC it is always unzippable if I change the extension to .zip, and on my Mac, I can always unzip it to see the Payload directory, and the MyAppiOS item inside it can never be opened - I get a popup "You can't open the application 'MyAppiOS' because it is not supported on this type of Mac." - in any case, the files Apple likes and the ones it doesn't look the same to me when I try unzipping.
My only ideas are to try to figure out how to open and build the app on my Mac, to call my router company, and to keep trying and trying, over and over again, until finally one of the builds works... which sometimes literally takes hours.
Many thanks for any help you are able to offer!
I try to index PDF files with Sitecore 7.
I installed IFilter , but I received on crawlers log next error :
ManagedPoolThread #17 09:24:20 WARN LuceneIndexOperations : Update : Could not build document data 4433434-3443-3223-91c4-233232. Skipping.
Exception: System.Runtime.InteropServices.COMException
Message: Error HRESULT E_FAIL has been returned from a call to a COM component.
Source: mscorlib
at System.Runtime.InteropServices.ComTypes.IPersistFile.Load(String pszFileName, Int32 dwMode)
at Sitecore.ContentSearch.Extracters.IFilterTextExtraction.FilterLoader.LoadAndInitIFilter(String fileName, String extension)
at Sitecore.ContentSearch.Extracters.IFilterTextExtraction.FilterReader..ctor(String fileName)
at Sitecore.ContentSearch.ComputedFields.MediaItemIFilterTextExtractor.ComputeFieldValue(IIndexable indexable)
at Sitecore.ContentSearch.ComputedFields.MediaItemContentExtractor.ComputeFieldValue(IIndexable indexable)
at Sitecore.ContentSearch.LuceneProvider.LuceneDocumentBuilder.AddComputedIndexFields()
at Sitecore.ContentSearch.LuceneProvider.LuceneIndexOperations.GetIndexData(IIndexable indexable, IIndexable latestVersion, IProviderUpdateContext context)
at Sitecore.ContentSearch.LuceneProvider.LuceneIndexOperations.BuildDataToIndex(IProviderUpdateContext context, IIndexable version, IIndexable latestVersion)
at Sitecore.ContentSearch.LuceneProvider.LuceneIndexOperations.<>c__DisplayClass7.<Update>b__0(Item version)
What I have to do work because on Sitecore documentation they said it must work out of the box.
I had the same issue and I received from Sitecore support next response (it works fine after):
1) Copy all the Adobe iFilter .dll files into the "\System32\Inetsrv" folder. This is the working directory for IIS on Windows Server.
The Adobe iFilter .dll files are stored at the "C:\Program Files\Adobe\Adobe PDF iFilter 9 for 64-bit platforms\bin" folder by default.
Also you can use the "IFilter Explorer" tool to detect the folder where the .dll files are stored:
http://www.citeknet.com/Products/IFilters/IFilterExplorer/tabid/62/Default.aspx
For more details please see the screenshot:
http://screencast.com/t/xmWukanM+
2) Delete all the files under the "Website/App_Data/MediaCache" folder;
3) Rebuild the Sitecore Search Indexes (Sitecore -> Control Panel -> Indexing -> Indexing Manager);
4) Clear the Sitecore cache (the http://{hostname}/sitecore/admin/cache.aspx tool);
5) Restart the IIS;
Here is the solution I took since I didn't like the idea of coping iFilter related DLLs into the system path.
install Adobe IFilter 9 (I used this link). Note version 9 is essential as starting at version X they abandoned file based interface.
add filter location to the PATH environment variable. In my case it was %ProgramFiles%\Adobe\Adobe PDF iFilter 9 for 64-bit platforms\bin\.
run iisreset
go back to Sitecore app and run index rebuild for necessary indexes.
For your consideration:
while trying to resolve the issue I granted full access to IFilter folder for app pool account. I don't think it's necessary as I removed it at the end and everything was still working fine.
After these steps PDF indexing started working fine on my instance of Sitecore 7 running on Windows 8.1.
Trying to run some of the desktop(AIR) samples located here
http://code.google.com/p/facebook-actionscript-api/
No matter what I try get the error message
Process terminated without establishing connection to debugger.
application descriptor not found
But as far as I can tell there IS a proper descriptor file (XML) present in my bin-debug folder.
Anyone have an idea what is happening? Could the issue have something to do with the Flexsdk I am using (4.6) when combined with the latest AIR 3.4?
This is my application descriptor file WITHOUT most of the commented code
<id>MediaUploadDemo</id>
<filename>MediaUploadDemo</filename>
<name>MediaUploadDemo</name>
<version>v1</version>
<initialWindow>
<content>MediaUploadDemo.swf</content>
</initialWindow>
Found most of my answers here
http://alpha-beta-pruning.blogspot.ca/2011/06/migrating-flex-3-project-to-flex-45.html
Key paragraph
'Each AIR sdk tends to have it's own application descriptor file formatting which means that an application that was created with AIR 2.0 must "migrate" its descriptor file to the new AIR 2.7 sdk. My suggestion is creating from scratch a new project that targets the new sdk, just so we can take its descriptor file, copy/paste it to our "old" project and change the necessary values to adapt our project (such as project name, etc).'
I have a Qt 4 application that is trying to connect to an MS SQL Server 2008 database using the Qt ODBC driver. The application runs fine when it is running in Windows; however, the target OS for the application is to have it run in GNU/Linux. When the application runs in GNU/Linux I get the following error:
QSqlError(0, "QODBC3: Unable to connect", " [unixODBC][Driver Manager]Data source name not found, and no default driver specified")
Is there something I need to configure on the SQL server or application side to get the connection to work?
I don't really know much about unixODBC, but have a look here:
unixodbc.org/doc/
For connecting to MSSQL, the following might be useful:
http://www.unixodbc.org/doc/FreeTDS.html
or .../FreeTDS2.html
Try to copy the odbc.ini file in ~/.odbc.ini . If not working again, try to copy the same file into /etc/odbc.ini. If this is not working, as these directories are different for different Unix systems, find all files: *odbc*\.ini and see if some of them are empty. If so, replace them with the correct .ini file.
I had the same problem and this solved it. But it's a really stupid solution, so I'm looking for a better one. Hope that helped (:
I have a batch file that tries to compile a static library using Borland C++ Builder 6.0
It is called from Borland make (makefile created with bpr2mak) which is called from a .bat file (used to compile the whole project with Visual Studio and some Borland C++ Builder legacy projects), which is called from a bash shell script running inside Cygwin.
When I run the .bat file directly from a Cygwin shell, it runs OK, but when its being run from a Program calling cygwin with Boost::Process::launcher I'm getting this error:
C:\ARQUIV~1\Borland\CBUILD~1\Bin\..\BIN\TLib /u bclibs.lib #MAKE0000.###
DOS-reported error: Bad file number
TLIB 4.5 Copyright (c) 1987, 1999 Inprise Corporation
opening 'MAKE0000.###'
** error 1 ** deleting bclibs.lib
It's a complicated scenario, but this Program which calls cygwin is run whenever we need to build our software package which needs to be build for various Linux distos and Windows 32 and 64-bit.
Note: It's the only Borland Project failing, the other compile just fine (it's the only static library using borland also, so it can be some problem with the TLib tool.
The problem was that TLib does not like to have his output redirected (seen here) without having an input pipe as well. Solved by creating an input pipe to in the Boost::Process::launcher using set_stdin_behavior
I'm just guessing here, but this may have to do with long filenames and/or spaces in paths.
1) Modify your makefile so it would save current environment to a file, immediately before executing the failing command (set > d:\env.txt & echo CD=%CD% >> d:\env.txt). Then run it both ways (directly and via program) and compare the environments of good run and bad run.
2) Using filemon from Sysinternals, capture logs of disk access in both cases (these logs are going to be huge, though you can uncheck everything except Open in the filter to reduce the size). Again, compare and check for clues...
3) Try instaling everything involved to paths conforming to 8.3 scheme.
This error is not related to C++ itself. It happens when your build script opens too much files (more than defined in DOS command processor environment). To resolve this issue try to set value of files variable to 253. For Windows XP this variable defined in the file %WINDIR%\system32\config.nt.
files=253
Seems it is known bug in Borland C++ tools. Here is description and possible workaround for this issue:
Problem: Some static Lib projects will
not link correctly when compiled. You might see something
like this :
J:\Borland\CBUILD~1\bin\..\BIN\TLib /u debug\jpegD.lib #MAKE0000.###
DOS-reported error: Bad file number
TLIB 4.5 Copyright (c) 1987, 1999 Inprise Corporation
opening 'MAKE0000.###'
** error 1 ** deleting debug\jpegD.lib
MAKE failed, returned : 1
Workaround : In some cases (where the "Bad file number" error is seen) it may be possible to work around this by specifying -tDEFLIB.BMK in the BPR2MAKE Options field, and Turning off the "Capture Make Output" option.
I have not tested it, but I hope that helps.