In the web portal of TFS (2015.2) if I click on the Explorer tab I get the content of the source control; the main window has displayed at the top the source control path ($/fooProject/barFolder1) and a status indicator. The project is set to TFVC.
In my fooProject that status is showing the outcome of a build that happened 6hrs ago even meanwhile other builds had been executed. All builds are gated check-in builds set to be triggered on different folders.
Even if I browse to different folders the indicator is showing the result of the same build. Isn't supposed to show the result of the build that is triggered by changes on that folder?
Where can I find the documentation on that part of the TFS web portal?
The build status only point to the build definitions which include the entire repository path like "$/fooProject". It does not show the status base on the folder you select.
Related
When I build a specific project there is an undesired file being copied into the output from a nuget package during the _CopyFilesMarkedCopyLocal task. I can't determine from the logs or a search of project references why the file is marked CopyLocal. Is there anything logged that could help? Or is there a property or item group that I can start printing out debug messages to track it down?
More details:
The file is part of a Nuget package, but it isn't directly referenced in the project where the copy happens.
The project where the copy happens is part of a large complex .NET Framework application. The project has 5 PackageReference , and 1 ProjectReferences. The ProjectReference project has an additional 17 PackageReferences and 7 ProjectReferences and the tree keeps going.
NuGet will generate obj\...nuget.g.props/.targets file that contains the reference.
This can be controlled via Dependency asset attributes - e.g. setting ExcludeAssets="contentfiles" on the PackageReference.
Using a binary log (adding -bl to msbuild/dotnet build invocations) and opening it in the structured log viewer gives you good search options in the logical build tree and the files / log output which can help find these files.
LPCXpresso has been working fine, up until some point where it just starts to rebuild the entire project every time a build or debug is initiated.
Is there a simple way to fix this broken behaviour and make it start building correctly again?
Was having the same problem. Did basically the same correction as listed...
project -> properties -> C/C++ Build. Then Refresh Policy tab and "Add Resource" button. Select the top level project. Clean and rebuild. This fixed the issue for me.
Here is what has worked for me - I am not sure if all steps are really necessary:
clean all projects (Project->Clean...->Clean all projects, don't start a build)
Close LPCXpresso
delete .metadata folder (maybe make a backup)
delete the Debug and Release folders from every project in the workspace
Open LPCXpresso - there will not be any projects in your workspace
import the projects: right click in the project explorer->import->general->existing projects into workspace
click browse next to "select root directory" and click ok (this selects the workspace directory)
Select the projects you need and click finish
build each project individually by right clicking on them in the project explorer and selecting "Build Project" (build the projects in the correct order of dependencies)
You will need to recreate the debug target, make sure that "build configuration" is set to Debug, and select "enable auto build"
This worked for me, but I am not sure what the magic step is/was. Good luck!
Additional Info
Sure enough, the problem came back, as it always seems to do. I did a lot more digging and stumbled upon this blog:
https://mcuoneclipse.com/2015/06/06/eclipse-project-refresh-policy-broken-incremental-build-with-external-make/
The crux of this is: if the setting for "Refresh Policy" under Project->Properties->C/C++ Build/Refresh Policy is set wrong, then incremental build may be broken and you may get full rebuilds.
In my case, I had started a long time ago with a demo project and renamed it at some point in time. The refresh policy tab had one resource listed, which was the original project folder name.
I deleted that resource, then clicked Add Resource... and placed a check mark next to the top level project folder.
After cleaning things and rebuilding, now the issue seems to be fixed!
I've got a fairly large MVC2 project in TFS which gets built automatically on checkin (Continuous Integration)
At present, the fully built version is dumped on a network share on our dev IIS server. \\Server\wwwrootLatest
TFS of course creates lots of sub-folders since it's just doing a build, it isn't even aware that it's drop directory is a wwwroot.
This means that to actually USE the build, we need to go and manually create an IIS App which points at the appropriate directory - which defeats the whole object of the exercise.
When we do a manual publish to that server, we use "File System" as the method and just overwrite the files in the UNC share \\Server\wwwroot
(When publishing to other environments, we use full-on MSDeploy.)
What I'd like to do is convince TFS to do a "File system" publish after the build completes and duplicate what we do on a manual publish eg:
Drop directory is \\Server\Build which would result in something like \\Server\Build\Project\Date.Rev\
After that is complete, we want it to publish to \\Server\wwwrootLatest - we can then set up the App once which will always contain the latest version but will still have a full history if required.
The only examples I've been able to find use MSBuild commands in the build definition (fine) but all use MSDeploy to do a full-on publish. I'm not sure how to automate what I want to do
Any help appreciated.
In your drop folder a folder named _PublishedWebsites is generated automatically. It contains files you need to put in wwwroot. You can use CopyDirectory build activity to copy them automatically.
I am using Visual Studio 2008 Professional to build a VB.NET console application. I have a text file that I want to copy to the output directory after a build. I would like to create a build event to do that, but I do not see a "Build Events" folder on the property page. Is there a setting where I can get this folder? Or, is there another way I can set up a post-build event to copy a file to the output directory?
The folders I see on the Properties page:
Application
Compile
Debug
References
Resources
Services
Settings
Signing
My Extensions
Security
Publish
Compile tab. Scroll down and right, click the Build Events button.
But, no need to do it that way, just add it to your project with Project + Add Existing Item. Select it and in the Property window set Build Action to "Content" if you want it deployed, Copy to Output to "Copy if newer".
I've created a custom control and a framework/IB plugin for it using the IB3 plugin template.
According to the docs the plugin should be built right into the resources directory of the framework. When I build my project the plugin is in the configuration folder (Debug) along with the framework instead.
This is the same behavior right out of the box when I create a new template. I tried changing the CONFIGURATION_BUILD_DIR to be $(BUILD_DIR)/$(CONFIGURATION)/FrameworkName.framework/Resources/ but got no change.
For grins I also tried messing with the install path, but also got nowhere. I've checked out a couple other open source projects to check their build settings, but they're identical to my own and yet their plugin is built and put into the resources directory as expected.
Don't mess with build settings. Instead, add a "Copy Files" build phase to the framework target. In the inspector for the copy files build phase, set the directory to "Resources". Add the plugin to this build phase by dragging the plugin product from the "Products" group in the "Groups & Files" tree in Xcode.
To get the built product of one Xcode target to be included in the resources directory of another Xcode target's product, you should find the product in the groups and files tree and drag the product into the copy "bundle resources phase" of the other target. You should also add a target dependency between the two targets with the get info panel for the target.
If you're seeing the built plug-in in the build products directory that does not mean that it wasn't also copied into the framework's resources directory. Xcode builds all targets into the build directory, and then copies (not moves) them into their final destination - which in this case is the framework's resources directory. One reason for this is that a product can have multiple final destinations.
Thanks, Barry. When I tried using a copy files build phase, IB wasn't able to resolve the connection between the framework and the plugin. It couldn't find the associated plugin for some reason.
However, after endless fiddling, I found that I was closer than I thought. Changing the CONFIGURATION_BUILD_DIR to:
$(BUILD_DIR)/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)/FrameworkName.framework/Resources/
and updating the framework search paths solved the problem for me. This isn't the behavior of the plugin template (at least on my machine) out of the box, so hopefully this will help someone else.