I am trying to build a Visual Studio Package project via Hudson CI. This is a Visual Studio 2010 project. The project builds fine in my dev box, but for some reason, I keep getting the following error only when building in Hudson:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\VSSDK\Microsoft.VsSDK.targets(378,5): error : Error trying to read the VSIX manifest file "obj\Release\extension.vsixmanifest". The system cannot find the file specified. (Exception from HRESULT: 0x80070002) [C:\hudson\workspace\MyProject_Daily_Compilation\Source\MyProject.VisualStudio\MyProject.VisualStudio.csproj]
I have verified that the file exists on disk in the following location:
C:\Hudson\workspace\MyProject_Daily_Compilation\Source\MyProject.VisualStudio\obj\Release\extension.vsixmanifest
What could be causing this issue?
You are likely to experience such error if the user you are running your build as does not have administrative privileges.
So there are 2 solutions:
1) Run your build (build server) with administrative privileges.
or if you can't really change the user your build server is running on
2) and you actually don't need to deploy the VS extension on the build server itself, set the DeployExtension property in your *.csproj file to false.
Microsoft.VsSDK.targets sets that property by default to true
<DeployExtension Condition="'$(DeployExtension)' == ''">true</DeployExtension>
but if you don't need to deploy that extension locally (but rather would prefer to get the *.vsix bundle built you can safely put
<PropertyGroup>
<DeployExtension>false</DeployExtension>
</PropertyGroup>
The original error is basically happening because the attempt to get the deployment path fails at some point in the build and disrupts successful vsix package generation. By setting the property to false the build doesn't attempt to deploy the extension locally (but a valid *.vsix is generated)
I am guessing you running hudson as a service. If so the "0x80070002 - The system cannot find specified file" could well be due to the user being used to run hudson does not have access.
The quick solution to this is change the "Log on" user for the Hudson service to be your normal account.
Related
I've been working with SSIS reading different files - from CSVs to XLSXs - with no problems. My paths are relative, so SSIS searches for the files from the project's folder.
Well, today my colleague tried to run a package and he got a curious error message saying that the file could not be found under the "C:\windows\system32" folder. There's no configuration that would point SSIS to that folder and with me and a third colleague it's working well.
After some investigation we discovered that the problem has nothing to do with the user itself, but with how the user opens the project. Since the beginning I've been opening the project by double clicking the ".dtproj" file. My colleague first opens the SSIS development interface then opens the project file from the menu.
Has anyone noticed that behavior? What could be the cause for that?
error message print
Microsoft Visual Studio 2008
Version 9.0.30729.4462 QFE
Microsoft .NET Framework
Version 3.5 SP1
Installed Edition: IDE Standard
This happens because the different ways of launching the IDE end up with different current directories for the IDE process. You can test this by creating a package with only a Script Task, with the one line:
MessageBox.Show(Environment.CurrentDirectory);
And then running this project after launching it both ways.
Double-clicking the project or solution file sets the folder containing that file as the current directory. (I assume this is standard Windows process launching behaviour when starting a process based on the file extension association.) SSIS packages then look in the current directory when the path to the configuration file is relative.
We use relative paths to configuration files all the time to simplify deployment, and have to always remember to open the solutions by double-clicking the SLN file.
I have created a Nodejs application (sdgnodeapp) in my OpenShift domain, and was trying to import the sdgnodeapp application using OpenShift Explorer into my empty workspace in JBoss Developer Studio 7.1.1 GA .During the Import-Application workspace, I specify the git-clone-directory to be the same as my workspace-directory, JBDS then throws an error
"Could not import project to the workspace.
Invalid project description.
OK
/Users/sddasgu/SDGDevCode/Node/NodeWorkspace/sdgnodeapp overlaps the location of another project: 'sdgnodeapp'".
NOTE: If I change the git-clone directory to some other directory (not my workspace-directory), then the project is added to my workspace as expected.
I am used to creating projects inside my workspace-directory, but it seems to me in the above case, that the git-clone happens successfully, but then then the project creation fails. Is there a way to circumvent this problem ?
This is caused by there already being a directory called 'sdgnodeapp' in your eclipse workspace. Rename the existing one directory on your machine in your workspace to something different and then run the clone command again. That should fix it
We are trying to configure a deployment of ASP.NET application using Octopus deploy.
All is working fine, but sometimes the step fails while trying to overwrite files saying the the file is already locked by some other process.
We already stop IIS before the deployment starts, so not sure what we can try here.
Sometimes the error is in the application customlog folder(txt files), sometimes its in the bin folder for some dll etc.
Exact error is:
*Unable to copy the package to the specified directory 'D:\Apps\XYZ_Stage'. One or more files in the directory may be locked by another process. You could use a PreDeploy.ps1 script to stop any processes that may be locking the file. Error details follow.
Access to the path 'D:\Apps\XYZ_Stage\bin\XYZ.Business.dll' is denied.
System.UnauthorizedAccessException: Access to the path 'D:\Apps\XYZ_Stage\bin\ACA.Business.dll' is denied.*
Any suggestions?
If you're using Octopus 2.0 or higher, you can leverage the "IIS web site and application pool" deployment option which causes Octopus Deploy to handle all the complexities of deploying to IIS without you performing manual steps.
Here's some information: http://docs.octopusdeploy.com/display/OD/IIS+Websites+and+Application+Pools
I ran into a problem creating a new project in Cocos2d-x 3.1.1 (or 3.0 - it happens at both versions).
When I'm running the build script in console (Windows 8 - console with admin privileges) an WindowsError pops up (check the image below).
http://i.imgur.com/Ixg4jEE.png
I can set up the COCOS_CONSOLE_ROOT manually, but it does not help with the Error 5.
I tried setting the 777 priviligies an all cocos2d-x folder and subfolders, but it does not help.
Anybody had the same problem? Any solutions out there?
On Windows you should not put manually installed programs and tools under C:\Program... (english: C:\Program Files) because that's a folder where only apps with a proper installer should go. Otherwise you will keep having permission issues. Apps are not allowed to write to that folder or any of its subfolders.
Since cocos2d-x isn't an app, it can't redirect its output to the proper AppplicationData folder as is mandated by the operating system. Not being able to write or modify the program folder's contents (except during installation) is a security feature in Windows that you can't (or shouldn't) bypass.
To fix this simply extract cocos2d-x in a folder that both you and apps have full read/write permission. Normally this would be in your Documents folder, but Desktop would also work and probably just any folder on a drive that you created, for instance C:\cocos2d-x.
Due to this line:
_winreg.SetValueEx() ...
the actual problem looks like to be with registry access, rather than with file permissions.
Make sure you actually running console as an admin, by:
searching cmd in Windows search, or just creating a shortcut to it to desktop
right clicking to cmd.exe and choosing "Run as administrator"
Make sure you don't have registry access block in any way: like blocking in group policies, some "security optimization" software and viruses and antiviruses.
Make sure your python version is 2.x. Python 3.x is not supported.
Anyway, this 'setup.py' step is optional for using cocos2d-x and you can live without running it at all.
We use Hudson CI as our build tool , when we refer to file system in the same server machine,where Hudson is running ,there was no problem.
But when we used File SCM plugin to point to file system in remote machine with all the read/write previleges ,it cannot check-out and failed with below error.
FATAL: Parameter 'directory' is not a directory
java.lang.IllegalArgumentException: Parameter 'directory' is not a directory
at org.apache.commons.io.FileUtils.listFiles(FileUtils.java:358)
at org.apache.commons.io.FileUtils.iterateFiles(FileUtils.java:404)
at hudson.plugins.filesystem_scm.FolderDiff.getNewOrModifiedFiles(FolderDiff.java:104)
at hudson.plugins.filesystem_scm.RemoteFolderDiff$CheckOut.invoke(RemoteFolderDiff.java:94)
at hudson.plugins.filesystem_scm.RemoteFolderDiff$CheckOut.invoke(RemoteFolderDiff.java:88)
at hudson.FilePath.act(FilePath.java:758)
at hudson.FilePath.act(FilePath.java:740)
at hudson.plugins.filesystem_scm.FSSCM.checkout(FSSCM.java:123)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1483)
at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:507)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:424)
at hudson.model.Run.run(Run.java:1366)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
There's a couple of things I can think of based on your configuration - please note that i'm not a Windows expert though.
Is your Hudson server running on Windows ? If not, the \remoteserver\d$\source\ format for the file system path won't work.
Does the user running Hudson have access to the remote file path \remoteserver\d$\source\ ?
I got this solved ,after i run the Hudson service with user id ,which has got access to the remote server location.