I have an automated build process that runs when no one in is in the office, and it pushes builds, deploys IIS web sites, and various other tasks. The problem is that if someone leaves a file open in one of these applications (like say they were looking at the web.config in a text editor), the build fails because it can't delete the files. I've seen people propose a solution as using Unlocker to release the file handles, but I don't want an interactive program - I want a command line application that I can call from the build process to release any open handles in the directory automatically.
Microsoft provide handle.exe which is a command-line tool. You'd need to do some ninja parsing to interpret the output, though. Also be aware that forcing a handle closed can have very unwelcome side-effects, it might actually be safer to kill the offending process.
Build from a separate copy of the source code. Leave the original copy for developers to inspect.
Related
I am new into software developing. I have found this GitHub repository which I plan to modify. Let's just say I fork this repository and modify it. How would I then be able to export it from there. By export it I meant turn all of those files into one windows executable file. Thanks.
In general, building a project is a project-specific task unless the project is written in a language (such as Rust) that has a built-in build tool. If you're unclear about the steps to build a project, you should look in the documentation or the wiki for steps about how to do so, and failing that open an issue asking them to document the procedure for building the project.
Just looking at the project, it does not seem obvious that it should produce a binary executable of any sort since it's written mostly in JavaScript.
Usually you use a compiler to turn source code into machine code (exe files).
As bk2204 mentioned, this project is based on Javascript and Node.js.
Javascript is interpreted instead of compiled, so another program (Node.js) reads the source code and executes it directly every time instead of first compiling it into an exe file. That other program itself may be in an exe file.
The project you have linked is a fork of this project, and that one seems to have a Windows launcher/installer exe file (that probably installs or contains Node.js, but I haven't checked).
That installer is available here in both exe and source code form. So you could modify the launcher and rebuild it, but the main app is not in the launcher, instead it's in all the JS files. You may be able to edit the JS files and just use the same launcher without modifying it. There may be a packaging step required after editing the JS files, to package them into a form that the launcher expects. You would need to run this build step after every time you modify the JS files, to provide the new code to the launcher.
You would have to explore the project's structure and build process to find out the exact steps.
If you're very new that may be exceedingly difficult.
You may want to practice by learning Javascript and Node.js.
You could after that try Java which is compiled, and possibly more powerful than Javascript. Just for fun.
Maybe you could do 30 of these practice projects, then you'll have a chance of being able to modify this project successfully.
I'd like to use visual studio to store in source control xml files coming from a server.
I have a request like http://server/query.aspx?FILE_ID=1234 that allows me to download an xml file. Those file are part of our development activities, that's why I'm looking for a convenient way of integrating those file in source control.
I'd like to have a project containing all the xml files I want to check-in in source control and add a pre-build command allowing to download the files, but I did not find any convenient way of doing it.
People have a tendency to forgetting to do it manually, and we have already seen all the possible scenarios: lost files, released version without the ability to know the exact configuration used, ... I'd like to automated this step so that it does not happen again in the future.
I'm sure there is a simple and smart solution, but I could not find it. Any suggestion would be appreciated.
You should be able to use wget in a pre-build action to fetch the latest version of the files. I can't think of a reason why that wouldn't work.
Personally i would consider finding a way to automatically commit those files to source control whenever they change on the server. I've never used tfs, but I assume there is a commandline-client which allows you to commit files in a scripted way. If you don't have any control over when the files change you could do this every N minutes on a machine which is always on.
You can write a (powershell) script that does the fetching, and checkin of the file before your build starts. That's how we fetch external assemblies to be included in our build.
To get you started, take a look at these powershell functions for TFS interaction:
http://www.brokenwire.net/bw/Programming/73/ (TFS 2008)
I'm looking for a utility that copies all files from a VS2010 solution folder, which are necessary to build the solution, but ignores all other files (.obj files etc). My intended use is for emailing solutions or making them available on a blog etc.
I'd prefer a utility that's portable (runs without having to be installed), but if there is none, I'll settle for whatever's available.
You may want to consider something as simple as a script (via .bat or powershell) that simply runs the solution's build with a /clean and then zips up the entire folder structure into an archive.
No need to be fancy, especially when project can need any number of impossible-to-know files to build. (What happens when a new language is released like F#? If you'd written your tool 3 years ago, you'd have to modify it for that. What happens if someone needs a .txt file or a .mak file to build?)
In the past I've created a new configuration within VS.NET (e.g. Deploy) which builds the code in release mode. I also set the output path for the main application project to build into a separate folder in the root of the project.
If it's a web application, this is a little more problematic as it won't copy the support files. To get over this I use a nant script to copy all of the appropriate files, that are needed but aren't included in the build, into the aforementioned build folder.
I'm trying to reverse-engineer a program that does some basic parsing: text in, text out. I've got an executable "reference implementation" and the source code to what must be a different version, since the compiled source output != executable output.
The process creates and deletes temporary files very quickly in a multi-step parsing process. If I could take a look at the individual temporary files, I could get some great diagnostic data to narrow down where my source differs from the binary.
Is there any way to do any of the following?
Freeze a directory so that file creation will work but file deletion will fail silently?
Run a program in "slow motion" so that I can look at the files that it creates?
Log everything that a program does, including any data written out to files?
Running a tool like NTFS Undelete should give you the chance to recover the temporary files it's creating then deleting. Combine this with ProcMon from Sysinternals to get the right filenames.
You didn't mention what OS you're doing this on, but assuming you're using Windows...
You might be able to make use of SysInternals tools like Process Explorer and Process Monitor to get a better idea of the files being accessed. As far as I know, there's no "write-only" option on folders. For "slowing down" the files, you'd just need to use a slower computer. For logging, the SysInternals tools will help out quite a bit. Once you have a file name(s) that are being created, you could try preventing their deletion by opening the files in a stream from another process. That would prevent the system from being able to delete them.
There are two ways to attack this:
Run various small test cases through both systems and notice the differences. Since the test cases are small, you should be able to figure out why your code works differently than the executable.
Disassemble the executable and remove all the "delete temp file" instructions. Depending on how this works, this could be a very complex task (say when there is no central place where it happens).
So this is a question for anyone who has had to integrate the building/compilation of legacy projects/code in a Team Build/MSBuild environment - specifically, Visual Basic 6 applications/projects.
Outside of writing a custom build Task (which I am not against) does anyone have any suggestions on how best to integrate compilation and versioning of legacy VB6 projects into MSBuild builds?
I'm aware of the FreeToDev msbuild tasks at CodePlex but they've been withdrawn at the moment.
Ideally I'm looking to version and compile the code as well as capture the compilation output (especially errors) for the msbuild log.
I've seen advice on encapsulating this functionality in a custom task, but really wondered if anyone has tried another solution (aside from executing shell commands) -
In essence, does anyone have a "cleaner" solution?
Ideally, executing commands using would be a last resort..
The VB6 task will be back on Monday. With regards to versioning, there is no explicit vb versioning task in the pack, however you could make use of the TfsVersion (TaskAction="GetVersion") and the File (TaskAction="Replace") tasks. If you think there is value in creating a new task to encapsulate / provide other functions, then please let me know and I will add it to the pack for the benefit of the whole community.
Apologies for the withdrawal, but come Monday I'm sure all will understand.
I am using Nant to build VB6 projects daily. This does resort using the Nant execute command to do the builds (we build 4 projects as part of one "solution").
It also allows you to label versions in your source control repository, get latest code, check in, check out, all the normal requirements, compile the update/setup programs copy the files to required locations and send emails of the results.
The logged results are fairly minimal though as you only get the output provided by a VB6 command line compile.
For versioning, I had to write a small app to extract the version number of my compiled executable and write it to a text file that Nant could then read and use (for labels, file names etc. (A bit of a pain but VB generated version numbers don't comply anyway).
For help with other non-core tasks see NAntContrib - from the NAnt link above.