I've got a nant build script (.86 beta) and it is telling me this:
BUILD FAILED
Failed to initialize the 'Microsoft
.Net Framework 2.0' target
framework.
The process cannot access the file
'C:\Users\cconway\AppData\Local\Temp\tmp25E3.tmp'
because it is being used by another
process.
This file does not even exist on my machine. Does anyone know the cause of this? Rebooting seems to allow me to run the script once successfully, but every time after that I get this message (though the name of the tmp file changes per reboot).
Thanks!
Are there any third-party tasks which might leave temp files open or keep running in the background, thus leaving file locked?
Maybe try sysinternals process monitor which will allow you to see the process which has the handle on this file.
Also, make sure that you have all the right versions of .Net installed and they are the correct ones (SDK vs Runtime). If you open the config file for nant you can see where it expects the .net version to be go check to make sure it's there and that you can see hte compiler methods (csc, vbc, etc). So it could have something that is trying to find it but it's not there or the pathing is off.
It is beta so there could even be a typo in the config file.
The answer is my anti-virus. I should have tried disabling that first! Once I disabled it, everything worked like a charm.
Hope this helps someone.
Related
I have a question regarding the nunit3-console. When running tests through it I am observing a generation of log files like internal-trace and nunit-agent text files.
I was able to disable the generation of the internal-trace with the --trace=off option but for each run having the test .dll specified I am noticing a nunit-agentNumber.txt file generated.
My question is, is this a problem? More specifically for CI/CD and is there an option to disable this? Or clean it at least after each run.
Version 3.15 of the engine introduced a new internal feature, allowing code to change the level of debugging dynamically. (Not yet exposed to users, but intended to be eventually)
As a side effect, it looks as if empty log files are being created. For the moment, the only way to avoid this is to go back to the previous release.
A fix was created in the development code for version 4.0, but has not been ported back to the version 3 code. A bug report might help with that. :-)
I am playing around with Microsoft's Q# library, and I've gone through the install, however the build is failing and I am having a tough time figuring out the problem. My first suspicion is Microsoft.Quantum.Canon
EXEC : error QS1001: Assembly E:\Projects\Quantum\Microsoft.Quantum.Canon\bin\Debug\Microsoft.Quantum.Canon.dll not found
I also have noticed Microsoft.Quantum.Canon.nuspec is missing. I've tried to do a Nuget.exe restore on the solutions but that did not work.
Has anyone worked through this?
It's been reported on GitHub already, although it appears to be intentional. See the comments in the .gitignore file:
# These files are generated by bootstrap from a .v.template (version template).
# Any changes must be done to the corresponding the .v.template file directly
Microsoft.Quantum.Canon/Microsoft.Quantum.Canon.nuspec
I can't find any info on this .v.template file, probably it's part of internal Microsoft build tooling. You can copy the template file and fill in the missing parameters if you wish, but the file not existing doesn't make the build fail , does it?
I just started using the included Development Kit that came with the CRM SDK. I created a simple plugin using the Development Kit and now I cannot find a way to debug the plugin. Before i started to use the Development Kit i was able to debug the plugins i created.
I attached the debugger to the w3wp.exe process but the debugger doesnt break on the breakpoint at all.
Moreover my assembly is registered on Database and with Isolation set to None
Any help would be greatly appreciated. Thank you
There is another way to debug (instructions toward the end), by copying the PDB to the CRM /bin and attaching to the asynchronous (or sandbox) worker process. I'm not sure which way is easier...I will have to try Piyush's way sometime, but I do not use the RegistrationTool anymore thanks to the toolkit:
Debugging works well once you follow the setup instructions, though
copying the PDB file remains a manual step. Also note, the sandbox
process (Microsoft.Crm.Sandbox.WorkerProcess) is not started until
after a plug-in is run, so you will have to invoke it (or another one)
at least once before you will be able to debug.
Some time back I wrote an Article to debug plugins in CRM 2011, this might help you out.
Debug Plugins - CRM Parking Lot
I found out what the problem was. Turns out you have to re-deploy the plugin after setting the Assembly with Isolation set to None. Then like Chris Snyder said you still have to copy the PDB file from the debug folder to the bin/assembly folder on the CRM server. Seems like that step is still manual. Will see if I can either find a way to do it automatically or just create a simble batch file to do it.
Thank you all for your help.
When I create a new window based application, I get:
Failed to launch simulated
application: iOS Simulator failed to
install the application.
I tried to do what this post suggest, but didn't work
Any suggestions? I haven't tried re-installing xcode yet.
Choose Reset Content and Settings in the File menu of the Simulator.
Build Clean in Xcode
Then try again.
I'm not sure why, but rebooting my machine seemed to fix it.
I had the same problem. A reboot also did the trick, but then I realized that the directory
~/Library/Application Support/iPhone Simulator/6.1/
looked "different" after the reboot (Directory "Root" was missing). So I tried to reproduce the error by deleting the directory or parts of it. The simulator each time recreated the directory and worked fine. Maybe the reboot is not really needed just recreating the mentioned directory would also help.
Try to delete project.xcworkspace file and xcuserdata dirctory in your project
It seems that the processes don't get cleaned up properly each time you stop the app with ps aux in Terminal showing a large number of processes representing your app on the simulator.
I expect some kind of upper limit is reached with the number of processes / memory. (Indeed I have found that XCode will fail to build because some posix resource can't be found because there isn't memory to load it)
A machine restart clears all of these dead processes and allows room for new ones. For me, I only have to do this after about 2-3 weeks of not turning my computer off, but I suppose what resources you have and how often you use the Simulator will affect it.
If someone knows how to clear all these dead processes without restarting, that would be useful please, killall ... doesn't seem to have worked for me, but feel free to add to this answer.
Simply go the info.plist file property and set 'Copy to Output Directory' to 'Copy Always' it will resolve your problem.
I have been used to working with VS2005 and 2008 - using msbuild, etc, but I have inherited a set of projects that have to remain in vc6.0 for now. I don't like opening each project in the developer studio and building. I prefer to build form command line (I am automating the builds). Is this possible?
I have tried the nmake utility, but I still need to open up the projects and save/export the make file. This is tedious if the project changes - each time I have to save the make file. nmake seems to work, but it had a problem when I changed the location of the project in my directory tree (I checked out of svn into a new clean dir to try the build). It seemed to have hard coded paths in it, but I will have to check on that - it might have been a different problem.
Any alternatives out there?
Eventually I will migrate these to 2008, but for now that is not an option.
I'm recording the most important part of your link here - Microsoft has a bad habit of moving stuff around and leaving dead links. Not only is this the most important bit, but it gives enough information to do a search if/when they move it.
Building a Project from the Command Line
You can build a Visual C++ project from the command line without first exporting a makefile (MAKEFILE, or filename.mak) and using the NMAKE utility.
The basic command syntax is
msdev FileName [/MAKE "ProjectName – ConfigName | ALL"] [/REBUILD /CLEAN /NORECURSE /OUT LogFile /USEENV]
where FileName is the name of your project (.dsp) or workspace (.dsw) file.
I think I found m answer here:
http://msdn.microsoft.com/en-us/library/aa699274.aspx
thanks all
of course you can automate. I haven't used vc in years, but I think the compiler is called c8.exe or wow, I can't remember silly little tidbits like that anymore, but look in your vc\bin directory at all the exes and it will be obvious by name.
you can write a batch file worst case. But I also remember the UI having a "create makefile" function. So you do that once, and then just run make from the command line and voila. or maybe it's nmake. Again, been a long long time.
Microsoft provides a command line driver for building Visual Studio projects. In VC6 it's called "msdev" (do msdev /? for a list of options).
At some point (probably VS.NET/VS 2002) they started calling the command line build driver "devenv" for some reason. It has a somewhat different syntax, but for driving builds the options are the same or similar.
We use automated builds at my work place. Essentially just a batch file i fire off from the command line. Let me make sure i am allowed to post some sample code before i go ahead and post it. But yes, it IS possible to automate the build.
Sample Code:
:::::::: CompileSolution :::::::::::::::::::::::::
call X:\BuildTools\bin\BuildVbProj.bat
%COMPONENTNAME% %SOLUTIONDIR%
%PROJFILE% %BUILDOUTPUTFILE%
%PREBUILDFILE% if %ERRORLEVEL% NEQ 0
goto BuildErrors
goto Cleanup
EDIT: The BuildVbProj.bat file ultimately calls VB6.exe in the Program Files\MS Visual Studio\VB98\ folder. Try calling it with "VB6.exe /?" or "VB6.exe -?" and it will show you a list of options. You can basically automate your process using those options.
There should be a similar exe for VC in the VC98 folder as well.
Another option which is less labor intensive is
Pulldown Menu (BUILD)
Select (BATCHBUILD)
Push Button (REBUILDALL)