I have read numerous MSBuild posts, but none seem to refer to a strange problem I am having.
In MSBuild.xml (.NET 3.5) I have the following:
<ItemGroup>
<JavaScriptFiles Include="..\js\jquery.translator-ms-1.0.0-debug-all.js" />
</ItemGroup>
I receive an error:
Error 188 Failed to read in the data for the path/file [..\js\jquery.translator-ms-1.0.0-debug-all.js]. The most common cause for this is because the path is incorrect or the file name is incorrect ... so please check your path and file names.
However, if I use a file in the very same folder as follows with like properties:
The build completes successfully.
Does anyone know the "uncommon" causes for this error?
Possible reasons for being unable to open and/or read a file:
It doesn't exist.
It is open in another process (either for exclusive access, or it's locked).
You don't have NTFS permissions.
You want write access but the file has the read-only attribute.
The combined length of the path and (your quite long) filename exceeds MAX_PATH (260) characters.
The file is on a remote server and there's a network problem.
You've run out of kernel resources (e.g. too many files or handles in general open). This is quite unlikely.
You have a physical disk error.
It turns out that having the "debugger" statement within this JavaScript file was the "uncommon" error in this case.
Related
I'm trying to analyze the code of a vb application in TFS.
I'm using SonarQube, with the TFS extension.
My issue is that, whenever SonarQube encounters a file which only has comments in it, it will fail with this message :
ERROR: Error during SonarQube Scanner execution
ERROR: Unable to register token in file the [filepath].vb
ERROR: Caused by: 21 is not a valid line offset for pointer. File [filepath].vb has 20 character(s) at line 1
All the files have the .vb extension.
I would just remove these useless files from the repository but the code is not mine and there are over 15K files.
Is there a way to avoid crashing on this type of files ?
Or avoid analysing files filled with comments and empty lines ?
I'm using WiX 3.5. Recently, the following WiX error started occurring frequently on the build server:
light.exe (,): error LGHT0301: Failed to open the database. During validation, this most commonly happens when attempting to open a database using an unsupported code page or a file that is not a valid Windows Installer database. Please use a different code page in Module/#Codepage, Package/#SummaryCodepage, Product/#Codepage, or WixLocalization/#Codepage; or make sure you provide the path to a valid Windows Installer database.
Which "database" does the error refer to? (None of the WiX source files have changed in a long time, so I doubt it's a code page problem.)
Other people have reported that this error may be caused by Trend Micro Office Scan, which is indeed installed on the build server. I asked the system administrator to exclude the build directories from the scan, but this error still occurs. How can I determine whether the virus scanner is the culprit? (The error doesn't always occur, so if I disable the virus scanner and the next build succeeds, I still don't know whether the error has gone away permanently.)
The "Disable the ICE validation" worked for me - just a setting through Visual Studio 2012 in the .Setup.
After studying the WiX source code and running Process Monitor, I found that excluding the build directories from the virus scan is insufficient.
Explanation: When light.exe runs, it creates the target MSI file in a temporary directory. (This file is the database that the LGHT0301 error message refers to.) After light.exe closes the MSI file, ntrtscan.exe opens the MSI file for read access and read-only sharing. Later, in the database validation step, light.exe tries to reopen the MSI file for read/write access, and a sharing violation occurs.
Solution: Exclude the temporary directory from the real-time virus scan. On Windows Server 2008, for example, this directory is C:\Users\«username»\AppData\Local\Temp.
This is a common problem with build processes and antivirus. The scanner will detect the new MSI package and try to scan it. Meanwhile the build process also tries to validate it by running the Internal Consistency Evaluators (ICE) suite and you get a failure because the database has a mutex on it.
You should just remove the virus scan from your build output folders. Alternatively decouple the validation from the Light command so that the antivirus scan relinquishes the MSI handle before you run the ICE validation.
I had the same problem which was actually really related to codepages and language settings of my system.
Adding English input language in Windows' regional settings solved the problem on my German Windows installation.
The real cause was Trend Micro real time scanning!
(The following is only for historical reference)
I followed #Michael Liu answer and solved the problem
I had the same problem.
I am not referring to Codepage (or SummaryCodepage) in any of those tags, or in fact anywhere in the WXS. Putting Codepage="1252" didn't change anything.
Finally, I tried adding
encoding="utf-8"
to the XML tag which previously only had a version='1.0' attribute. This fixed the problem, as described in "Failed to open the database" error. - SOLVED
It was also the antivirus program for me.
An easy way to check if the problem is related to the anti-virus program is to disable the ICE validation in the WiX project setting (using version 3.7). This worked for me, and is a permanent setting now, since in our company you can't change the setting of the antivirus software.
This is the most common error I found while using WiX. The easiest solution for this is go to Properties of your project → Tool Settings → (Check) Suppress ICE Validation.
I'm trying to deploy a package with WebDeploy V3.
The installation process is to sync between a source folder to a destination folder on the remote computer and run a certain powershell script after the sync is done.
The command being executed is:
'"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -verb:sync -source:dirPath='C:\source' -dest:dirPath='D:\destination',computerName=XXX -postSync:runcommand='powershell -inputformat none D:\destination\Install.ps1',successReturnCodes=0'
This yields the following error:
Info: Using ID '49edd786-d8a0-4acf-be7b-95dd6e1391cc' for connections to the remote server. Performing '-postSync'... Info:
Using ID '5ef9d005-82fa-4811-9f51-1741c8d622de' for connections to the remote server.
Info: Adding MSDeploy.runCommand (MSDeploy.runCommand).
Error: (11/28/2012 4:34:24 AM) An error occurred when the request was processed on the remote computer. Error: The entry type 'Unknown' was not expected at this time. The serialization stream may be corrupted.
Error count: 1.
Error during '-postSync'. Total changes: 0 (0 added, 0 deleted, 0 updated, 0 parameters changed, 0 bytes copied)
Searching the net for this error, I didn't see anybody who encountered it when using runcommand provider. If anybody encountered a similar issue and has ideas or suggestions I would be most thankful..
From what I've seen, using runCommand to execute an arbitrary command line might be a bit buggy. Try moving the commandline into a bat or cmd file and providing a (full?) path to that. The file will be uploaded and executed, as long as you don't try to pass in any arguments to it.
For future viewers of this post: I encountered this same specific error (Error: The entry type 'Unknown' was not expected at this time. The serialization stream may be corrupted) after adding runCommand provider usage to my MyProject.wpp.targets file for the Web Publishing Pipeline MSBuild process. The path was direct cmd shell input used in order to clear readonly flags with attrib -R.
In my case, my build server was configured with WebDeploy 3.0, while the server targeted by the deployment package was configured with Webdeploy 2.0. After upgrading the target server to Webdeploy 3.0 this particular problem was resolved.
However due to other errors surrounding runCommand (providing the correct path to the destination executable at package runtime) my solution still doesn't work entirely so take this all with a grain of salt.
Warning: imagejpeg() [function.imagejpeg]: Unable to open '/home/SITENAME/public_html/files/cache/052f225905c1618003df0c5088aec7a9.jpg' for writing: Permission denied in /home/SITENAME/public_html/concrete/helpers/image.php on line 172
I emptied the cache directory and still no luck, and if I change the permissions on the cache folder then I get another error and I can't use the site at all:
Warning: require_once(Zend/Cache/Backend/File.php) [function.require-once]: failed to open stream: No such file or directory in /home/MYACCOUNT/public_html/concrete/libraries/3rdparty/Zend/Cache.php on line 133
Fatal error: require_once() [function.require]: Failed opening required 'Zend/Cache/Backend/File.php' (include_path='.:/usr/lib/php:/usr/local/lib/php:/home/owen/php') in /home/MYACCOUNT/public_html/concrete/libraries/3rdparty/Zend/Cache.php on line 133
I don't get it? I've never had this problem before.
Sounds like a permissions problem to me, but we can't tell from this end.
If you can FTP (or CD) into that /home/SITENAME/public_html/files/
and see if 'files' is owned by, and has the same permissions as public_html
Then see what permissions they NEED to have for your hosting setup.
Check that directory exists.
Check if web server daemon, most of the time - www-data, has write permissions to that particular directory.
For future reference the problem was the PHP handler. It has been changed to CGI mode (as opposed to DSO) and they turned suEXEC ‘off’ - might be useful for someone down the line.
I am currently trying to build a Resource DLL on on Windows Server 2003 and 2008. I am currently working with the Resource DLL code samples supplied with the Windows SDKs, and I can't get them to work.
On Windows Server 2008 I succeeded compiling the Windows 7 SDK ClipBook Server sample, but couldn't get it to properly work in the cluster. When I insert the resource as a resource type to the cluster using "cluster restype /create /dll" it works, but the resource is listed with an unknown type instead of a ClipBook Server type, as I think it should have as it is the type defined in the Resource DLL's code.
I also succeed in creating a resource of that type, but I can never get it to go Online. I always get the error:
System error 5079 has occurred (0x000013d7).
The specified node does not support a resource of this type. This may be due to version inconsistencies or due to the absence of the resource DLL on this node.
And this is despite the fact that the resource is located on all the nodes in the cluster including the one I try to start the resource on.
On Windows Server 2003, I'm working with the Platform SDK version 5.2, and I can't even get the ClipBook Server Resource DLL code sample to compile. I always get MIDL1001 Error saying that it cannot open the file cluscfgserver.idl. I added the path of the file's location to the include path of the project. That didn't work. When I tried to hard-code the path of the file, I got several linker errors when trying to link with this file.
If anyone knows anything about any of these problems, I would appreciate any input.
Those examples are old and busted. Here are a few things I had to go through to get the similar "File Share Sample" to work:
Convert the project to x64 (supposedly 32 bit resources still work, but I haven't been able to verify that)
Add the module definition file (.def) to the linker input property page so that the Startup function is exposed
There were several spots in code where CompareString is used to check the resource type name and 0 is expected on success, but it actually returns CSTR_EQUAL (3).
This is probably why you get the "(Unknown Type)" name.
To register the resource extension, cluster.exe won't accept spaces in the dll name, so in my case I had to use cluster /REGADMINEXT:'FILESH~2.dll'
Only the Property Sheet extension interface is supported, everything else (context menu, wizards) has been removed as of Server 2008
Check the extension DLL stdafx.cpp sources for the Resource Type "ClipBook Server". It should be "ClipBook Server Sample": const WCHAR g_wszResourceTypeNames[] = L"ClipBook Server Sample\0"