I am running a set of tests for work that I inherited from the prior testing. Most of the tests run fine from the central bin directory. One project, however, always fails because the current binary location (as seen by checking the value at Assembly.GetExecutingAssembly().Location) is showing up in temp directory like "TestResults\username_OPSNASJVJBX06 2016-02-18 11_40_06\Out\" off of the solution directory instead of in bin. I've tried recompiling. I've tried changing the project settings. I've tried modifying TestSettings.testsettings as per a handful of other people who've run into this issue. None of it is solving my problem. The most frustrating part is that this did work about two weeks ago, but I couldn't figure out what I'd done to fix it, and it later seemed to revert back to using this directory.
I have checked the project settings and not only are all of the test projects set to export to the ..\bin folder, but this test project's files show up there correctly.
As it turns out, the project was not set to use the TestSettings.testsettings. The path was absolute, not relative, so when I copied it to the test box, the link broke, quietly turning off use of TestSettings.testsettings.
Related
I have 2 VS Code workspaces for Go development, in both cases using Go modules.
In the first workspace I get red/green bars in the gutter indicating test code coverage. All very nice.
In the second I cannot get the coverage to show. I know the tests are running (being run by VS Code), using go test -coverprofile... and I can check the output and it looks good. I originally had a multi-root workspace but I tried creating a new one with just a single root for the module I'm working on. I tried making sure the root path did not include symlinks.
I have spent several hours now looking at the differences between the settings at user, workspace and folder level for the two workspaces and cannot find any differences.
I would appreciate and suggestion on how to track down why the coverage highlighting is not showing.
I'm using go 1.13.15.
Update
I have updated to VSCode 1.51.1 and go 1.15.2. No change.
However, when I use a git diff then I do see the coverage in the gutter, just not in normal editor views
I had a similar issue - I migrated from dev machine #1 to dev machine #2, and had the exact same environment, software/tools versions, etc. Code coverage worked as expected on dev1, but not on dev2.
The critical difference was that, on dev2, I connected to a vscode workspace that was a symlink of my gopath, whereas on dev1, that path had been a proper directory. When I connected to my vscode workspace on dev2 to the underlying directory, and not the symlinked version, code coverage began to display correctly.
I've recently downloaded GPUImage which is made up of one large directory containing the framework and various sample projects within it. Usually when I run a project it's simply one folder containing the project and everything works fine. However, when I run one of the sample projects within GPUImage, it's not recognizing the provisioning profile. When I move the sample project out of the GPUImage folder on its own, the provisioning profile error goes away, but then I get a bunch of new errors about it not being able to find the framework and other things (I messed around with moving stuff around but it turned into a disaster).
I'm wondering, is there a path somewhere that I need to change to get Xcode to work like normal when running a sample project from within the GPUImage directory so I don't get the provisioning profile error?
The problem was, somewhere along the line I deleted my team provisioning profile! Didn't realize it, but I was also unable to run any other sample projects that weren't created by me.
I don't recall having this problem before I migrated to my Retina MacBook Pro, but since doing so, my projects have insisted on loading in the "old" development location. In years past, before XCode 4, we put all our products in /Development/Products. And, after migrating to the new MacBook Pro, they're going back there again. I can use 4.3 or newer and see the same problem with both, so I'm assuming it's some kind of configurable that's at work here.
Of course, the first thing I did was verify that the Preferences/Locations was set to Build Location = Unique. I confirmed this both in the GUI and by popping open the .plist to check the value of IDEBuildLocationStyle and it was set to Unique.
I tried removing my existing configuration files (everthing in ~/Library/Preferences/ named Xcode) and that succeeded in changing the behavior to putting the output in the build directory of the project itself (really not helpful in my world as I have complex multi-project workspaces). Quitting and checking the settings, they were set for IDEBuildLocationStyle=Unique.
So, I copied the working configuration from another machine I had to this one. Since it too had previously had the /Development/Products destination, but had subsequently been moved to the Unique build style, I expected that to work. It did not. It instead returned the output to /Development/Products.
Thinking it might be something with my Xcode install, I created a new user and built from the same source tree (not a duplicate, not a copy, the exact same files). In this case, the output went to the right place (unique subdirectory of the Derived Products for that user). So, I blew away the ~/Preferences/*Xcode* again and copied in the preferences from the new user. Unfortunately, this took us back to the same behavior that the uninitialized configuration had, which is to say building in the build directory of the project itself.
I restored to my backup configuration files, and now I'm back to working at /Development/Products, but this isn't a good long term solution.
When checking the script output for a test script, I can clearly see that somebody is setting SYMROOT to /Development/Products in the case of the older config, and build in the case of the default configuration file.
Clearly there's something here on this system that's influencing the configuration, but I cannot figure out what it is. Any assistance would be highly appreciated!
Also - When I try to use option-Clean to enable Clean Build Folder, it is never enabled, which makes a certain kind of sense, but I thought it might be another data point.
I tried the solution in Strange behavior of Xcode Build Products Path under Build Locations and that had the same result as deleting the preferences: build products as children of the project directory.
Has anyone else seen such a problem? Have you found a solution?
Well, after a very long time of suffering through this on my laptop, I was finally able to track down the problem.
Inside of:
project.xcworkspace/xcuserdata/<user>.xcuserdatad/
there is a WorkspaceSettings.xcsettings file.
It contained a key BuildLocationStyle, which was set to UseTargetSettings.
Deleting the file and thus resetting this value allowed me to get both the Clean Build Folder... working and to get my project building correctly.
Hopefully this will help somebody else.
I use Linux as primary operating system and I also have to work on a Windows virtual machine with Eclipse 3.7.
We're working with subversion but with Linux I'm happily using git-svn with Emacs+magit, which works great.
So I would like to be able to work on the same code from both OS, and only do the real version control management on Linux.
So I had the following thought:
1. share the directory with virtualbox
2. create the projects pointing to the shared directory
Well that doesn't work, because the dumb thing wants to copy everything.
So I tried to use virtual folders which seemed a good idea, but now some scripts are badly failing because they don't find the hard-coded paths.
So I don't know anymore what to try, any idea?
EDIT:
My last attempt in the last edit would not work, so I have a simpler question.
Given a git/svn/whatever repository checkout, why can't I simply tell to Eclipse create a project there without touching the files?
Is it so hard for Eclipse to create it's .project in that position?
And since there is clearly no "supported" way to do it, is there maybe any workaround?
From my experience, the stages are the following (using Indigo version):
1. Create new empty project
2. Click File->import->file system
3. in the import window import file system, check the files you want into the new project folder
4. Click on advanced in the import window and tick "create links in workspace"
The new project should contain links to the original directory.
Eclipse modifies and compiles source in its workspace. The first level of the workspace is the project directories, + a .metadata which is local only to that workspace instance. Traditionally, the workspace contains the projects it works on.
Eclipse also supports 2 linked modes. In one, when you create the project in the workspace you give it an absolute path to somewhere else on the file system. This is handy if you have eclipse projects in a git repo, for example.
In the other mode, you create the project in your workspace locally. Then you link your folders (source, resources, whatever) to somewhere else on the filesystem. This is useful for projects that don't want to save the eclipse specific files (.project, .classpath, etc) in their SCM.
You have to create a different workspace on each OS (there's no way around that). But you could create the projects in each workspace and link to the common location (I don't recommend it, but it would be do-able).
Same problem here and finally got a solution!
1) clone your repo but not directly to your workspace, in my case I used workspace2 instead of workspace.
2) On eclipse, import all the projects on workspace2, but don't mark the "copy files to workspace", so the source code is left on workspace2.
3) On git you will see changes appeared, on project.options files (only file date is changed) and in .path files (some lines changed its order). As all of them are irrelevant changes, reset the local branch discarding those changes.
Thats all, git sees no more changes and eclipse open the files properly!
I ran into a weird problem worth commenting here: after importing i went to "git gui" to see changes, and the first file changed was a "project.options" file that only changed its date but the diff was empty (as the content was unchanged). There is a bug on git that makes git gui enter on an infinite loop: while it detect changes on file and diff is empty, a rescan is performed, then the same change is detected and enter on a rescan loop.
There is a patch to solve this, but it was easier just to add a silly comment on that only file (not in all your project.options) and then "git gui" was happy again and i could reset the changes on the branch.
I have a solution in Visual Studio that is comprised of 5 projects. The projects build to assemblies (.dll). I have the output path of each project set to \my-web-server\wwwroot\bin, which works fine on one project. In the properties for all of my projects, I have the output path set to the same directory, but when I try building all but one of the projects, I get the error:
Unable to copy file "obj\Release\Index.dll" to "\my-web-server\wwwroot\bin\Index.dll". Access to the path '\my-web-server\wwwroot\bin\Index.dll' is denied.
I assume it could be an issue with permissions, because my organization keeps things locked down, but I have no control over granting permissions. Any help in the right direction is much appreciated.
It must've been something silly. I deleted the .dll manually, then rebuilt. Looks like everything's working normally. Thanks.
The solution for me was to delete everything in bin and obj folders in every project. Just ran this powershell script as described here.
I had the same issue. A copy of Visual Studio (devenv.exe) was still running invisible in the background keeping the particular dll locked.
Delete all DLLs from the bin folder and build the solution.
just had the same issue, built a new project/solution, got it all working and then added to TFS.
Unfortunately I did not clean the build before adding and this meant some files that should not have been under source control were and were then read only(not checked out).
Manually deleting the files before rebuilding fixed the issue.
Most likely a program is running using that library.
This happens to me when running something to debug, and I forget to close it (not attached to IDE debugger).
And since this looks like a website, it is potentially due to the website being hosted from the development build folder, and someone is accessing it.
Similar to what Aequitarum said, it's mostly likely a locked file because it's in use. Since you have multiple projects, you mostly likely have references between them. And since you have all the projects outputting to the same folder any of the referenced projects will most likely get copied more than once if you have those files set to be deployed in the child project. (In a C# web application, you can view the properties of the reference and look at the "Copy Local" property.) And if you have the MsBuild project set to use multiple processors for the build, two child projects are both trying to copy the file at approximately the same time and one is erring out.
It's a very unique situation, but it is possible.
Working solution
Just go to Task Manager and search Detail (if its Win10) and search with your application name (for easy search just look at your windows user id wise)
And right click shows properties. just give the permission like Administrator access.
That's all its working fine for me. ( I was struggling for 1 week and its killed more my time)
It looks like WSearch Service locks up the files and does not release them. I disabled the service on WINDOWS 10 and was able to rebuild the solution.