I am trying to run an (empty) batch file from a customized TFS Build Definition, but every time the process hits the "Run Script" build activity, I get a "Directory Name is invalid" error.
We are using TFS 2013 Update 4 on Windows Server 2008 R2 Standard, and I am running Visual Studio 2013 from a Win 8.1 Pro on my dev machine.
The batch file in question is at "C:\Builds\SP_Base" on the TFS Server (as shown in the test condition in my customized build template. Here's the template itself (based on GitTemplate.12.xaml, since we are using Git as our source control):
This is the definition for our "Run Script" action:
From the log file, we can see that the test for the directory with the batch file passes without an issue. The same log file then shows the error:
Does anybody know how to resolve this, please?
I've seen other threads discussing the "directory name invalid" issue in other contexts, and the closest match was the one referring to the fact that cmd.exe gets invoked without sufficient privileges.
If we are looking at a symptom of a similar issue here, then what should I do to invoke cmd.exe from a TFS build process without errors?
Currently this is what I have if I look at cmd.exe's properties:
In answer to my question about how to invoke cmd.exe from TFS build process...
I found I can use InvokeProcess activity instead of RunScript in my customized build template. This article helped.
This is my new custom template xaml (including error handling for InvokeProcess):
Also, having added variables ExitCode (Int32) and ErrorMessage (String) as per article, the properties of the InvokeProcess activity now look as follows:
Please note the leading "/c" term in Arguments property for InvokeProcess. Without it, the activity will run and return no error, but the script will not get executed.
Hope this helps somebody with a similar issue.
Related
I recently updated Jetbrains Team City to version 2020.2.2. I use it to build my project whenever I check code into my source repository. I use the TeamCity API to DownloadAll in order to retrieve an Artifacts.zip that contains all the files generated by the build.
The recent update has a bug in it which is corrupting the Artifacts.zip file that is downloaded.
I am now getting an InvalidDataException "A local file header is corrupt." when My program calls System.IO.Compression.ZipFile.ExtractToDirectory() on the Artifacts.zip file.
I am able to right click on this very same file and unzip it using the built in windows "Extract All" and also with 7-Zip extract to folder. No problems with those, but for some reason, my program throws the above exception.
I use the following command on the Team City API to get the file:
https://{myserver}/httpAuth/repository/downloadAll/{myrepository}/{buildId}:id/artifacts.zip
Does anybody know why this would have just started happening on February 1, 2021?
I wrote up a bug on the JetBrains Team City site describing the above problem. They responded this morning with a fix. This appears to have been introduced with TeamCity Enterprise 2020.2.2 (build 85899):
Please add an internal property: (Click blue link to the left for instructions on how)
teamcity.internal.artifacts.useZip64=false
We applied the above property, and the problem was immediately resolved. No reboot of TeamCity was necessary.
Here is a LINK to the bug/solution on the JetBrains TeamCity site.
Using Visual Studio 2017 on Windows 10, I have a WPF application with an installer created using the Visual Studio Installer extension. When I install it on another PC, the application starts but then exits within the same second. Nothing in logs.
If I add a manifest to force admin mode, its starts correct.
If I copy the files to another folder (outside program files) it starts correct.
Apparently the "program files" is restricted or something? Am I missing something in my setup/installer project? Any other ideas more than welcome!
EDIT:
I've tried to create the installer using WIX and then it runs fine. Seems to be some settings in the VS Installer extension.
You can modify the ACLs on the folder in question to allow write access by regular users (not great) or you could write the settings file somewhere else where write permission for users is standard.
There are many ways: Resolve lacking permissions.
There is another, similar answer here.
Adding a couple further links:
WiX and deployment links, various topics.
I created a new free-style software project and under "Configure", I added a "Execute Windows batch command" under the section "Build".
My command in the text-box is as follows:
call \\ukvc-miu29-12\c$\Testing1\testing.bat
My console output when I try to run my build is as follows:
Started by user anonymous
Building in workspace C:\Program Files (x86)\Jenkins\jobs\Run comparison script\workspace
[workspace] $ cmd /c call C:\Windows\TEMP\hudson1649447975658279345.bat
C:\Program Files (x86)\Jenkins\jobs\Run comparison script\workspace>call \\ukvc-miu29-12\c$\Testing1\testing.bat
Access is denied.
C:\Program Files (x86)\Jenkins\jobs\Run comparison script\workspace>exit 1
Build step 'Execute Windows batch command' marked build as failure
Finished: FAILURE
Have spent close to two hours looking for a solution online, but I am unable to find one.
New to Jenkins, so any suggestion/s is/are appreciated, thanks!
I guess Jenkins runs as another user than the one you're logged in with. So that user probably isn't allowed to access that network share (or doesn't have the login credentials cached).
The easiest way of making sure it will work, would probably be to add the same user with the same password that Jenkins runs under to \\ukvc-miu29-12.
(As for the call, I'm not sure you really need it and I have a vague suspicion that you end up failing the build every time if you use call here. The temporary batch Jenkins executes there looks like it relies on the fact that control won't return if the batch file was executed successfully. But that's just a guess on my part.)
I have a simple Windows Form application(WPF) with entity framework. After compiled, only a few files generated:
EntityFramework.dll
EntityFramework.xml
MyApp.exe
MyApp.application
MyApp.exe.config
...
Then I just copy following files to a network shared folder:
EntityFramework.dll
MyApp.exe
MyApp.exe.config
Then I can double click on MyApp.exe from developer computer the launch the app, but can not launch from another end user computer.
How to resolve this problem?
When you double click, app is not launching means certainly it is crashing so type the command eventvwr in run or cmd it'll open the Event viewer in that go to Windows Logs and Click on Application, you can see different levels of logs in that just find the last error log view the details it might help you
Have a look in the event log on the target computer and look at the error that is actually being reported.
It could be a missing installation of the correct version of the DotNet framework as suggested in the comments above, or it could also be that the execution policy of the target computer is preventing the user from running from a network drive (As a developer you probably have admin rights on your local pc allowing you to do this).
Whatever the actual cause you are always better to use some form of installer, rather than this form of putting files on the network (commonly known as xcopy deployment).
Probably the best solution is to use Visual studio to generate you a click once installer and publish it to your network drive. This will then copy the application locally on the users pc and run it from there.
We have a silverlight(5) project, the source in TFS (2010) and Continuous Integration build has been setup and working fine. However, we are now at the stage where we are trying to release it to some users to get them using it and give feedback. I've set up the code so that it checks for updates and if there are any it downloads the latest xap file. However this requires the xap file to be signed. No problem when doing this from our dev machines, but when it comes to the automated build it fails, with the message
Xap packaging failed. Cannot locate the signing tool SignTool.exe.
I've tried numerous things to get the signtool to be recoginised and can't. However, we don't actually need this on the CI build, so I've then tried a second tack which is to make the postbuild event conditional on being run in VisualStudio. Followed various suggestions here on SO but can't gett them to work.
The post build event is
if "$(BuildingInsideVisualStudio)" == "true" (
"C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\signtool.exe" sign /f "$(SolutionDir)castle.pfx" "$(TargetDir)Castle.xap"
copy "$(TargetDir)Castle.xap" "$(SolutionDir)Castle.Web\ClientBin"
)
still no joy. Have tried multiple variations of this, but keep getting the same message from the automated build.
So can anyone help with either a) getting the signing tool to be recoginised on the build server or b) getting the automated build to skip the postbuild event?
Found the problem in the end...
I had been putting in place some features so the app would download and install the latest xap file. This requires it to be signed. As this wasn't working I followed some instructions on signing a xap file, not realising that one of the other developers here had put in place the code I described above in the post build event.
I had mistakenly thought that this was created as a result of me checking the 'Sign The Xap File' check box.
So first issue was that other developer had not shared his pfx file with us to add to our certificate stores.
Second, and main issue, was that we then had two attempts at signing going on. The one via the check box and the one via the post build event. I removed the check box and it worked fine.
The issue with the check box is that it expects the SignTool.exe to be in a particular location. On our development boxes with full VS it is where it is looking for it, but on the build server it wasn't. Think it may also have something to do with 64bit machines.
By using only the build event (once you have the correct certificates installed) you can specify explicitly the location that the signtool is going to be, and if necessary install the windows sdk to that location.
This is the top result in Google for this error so updating it with my steps to resolve.
The above didnt work for me but performing the steps below should fix it.
Install the Windows 8.1 SDK on the build server (Windows 2008 R2 for me)
Adding the Windows SDK BIN directory (that contains signtool.exe, on my server) to the Environment PATH variable - e.g. c:\program files (x86)\Windows Kits\8.1\bin - note: Do not add quotes around this
Restart all the Visual Studio Team Foundation services in services.msc after you add the file path to the PATH variable as it needs to reload these before building