I think I may have misunderstood the purpose of this function, but here's my problem.
When I look in the build summary, I see that a build ran successfully, and it tells me:
[person] triggered [build number] ([project]) for changeset 123456
I have the following code, which runs in a console app to tell me what changesets were included in a build.
IBuildDefinition[] result = buildServer.QueryBuildDefinitions(teamProj.Name);
foreach (IBuildDefinition def in result)
{
IBuildDetail[] dets = def.QueryBuilds();
foreach (IBuildDetail det in dets)
{
det.RefreshAllDetails();
// Get changesets for the buildList<IChangesetSummary>
changes = InformationNodeConverters.GetAssociatedChangesets(buildDetail);
foreach (IChangesetSummary changeset in changes)
{
}
}
}
The problem is that this returns nothing. The Information propery has 6 nodes, none of which relate to a changeset or a workitem. Why does VS2010 build summary tell me that I have an associated changeset, but the code below tells me different?
What is the state of the build? (Successful, Failed, or Partially Succeeded)? Also, which build process template are you using? Are you using the default build process template and if you are have you made any updates to it? There are a few things that you have to make sure you keep in place if you customize the build to get the AssociateChangesetsAndWorkItems build activity to work properly.
I helped Andy Lewis with some of that information here: http://blogs.msdn.com/b/andy-lewis/archive/2011/01/31/how-good-was-that-build.aspx
The string you mentioned isn't actually what indicates that there are associated changesets. On the build summary screen, you should see a section that says "Associated Changesets." If you don't, then that usually is the first sign that there is a problem.
Let us know some additional information and I'll be happy to help!
Related
[Steamworks.Net] SteamAPI_Init() failed. Refer to Valve's documentation or the comment above this line for more information.
It works fine in the Unity editor, but somehow I get an error with something built for Windows.
The code is below. Very simple.
if (SteamManager.Initialized)
{
string playerName = SteamFriends.GetPersonaName();
Debug.Log(playerName);
}
else
{
Application.Quit();
}
My username appears in debug in the editor. However, the build closes the app.
My app has not been published yet and I have not submitted any builds.
But, the fact that the editor can identify the user maybe means that something went wrong during the build process.
I created a steam_appid.txt at the root of the project and entered the AppID.
What's the difference between playing in the editor and playing a build?
Someone teach me please. Thank you. (Google Translated)
I don't know why, but when I submitted the build to Steamworks and installed it on Steam, I got no errors.
But uploading a build every time is very tedious...
I fixed it by placing the steam_appid.txt (containing the steam app id) next to the exported/built exe file
In your editor Unity. You must make sure:
App ID in the root folder(Asset(Not include inside Assets),,...,steam_appid.txt) config true with your app id created on a partner.
The steam app must run with runtime editor launching to confirm init.
--
I think your config and setup have error process. So I recommend you read more on 2 repositories:
https://github.com/rlabrecque/Steamworks.NET
https://github.com/Facepunch/Facepunch.Steamworks
I have a problem with parsing steps in .feature file with implementation which is defined in steps.cs file. Beside that, the same step was parsed successfully just a few lines upper in same scenario in .feature file. All steps bind successfully, with exception of last 2 steps, which fail to bind, although these steps appear for 2nd time.
I tried to delete .cache files in %TEMP%, but it is not that. Besides that, step definition is like:
From steps.cs file, when I do Ctrl+Alt+Shift+S, I get 2 steps recognized, which is ok.
We use VS 2015, specflow for VS2015, and SpecFlowSingleFileGenerator as generator. Same happens with VS 2019, with specflow for VS2019 and SpecFlowSingleFileGenerator as generator.
I must say that we have a plenty of scenarios and features which behave nice (with very very basic regex).
Anybody got any clue for this?
Also, when I enable tracing (Tools->Options->SpecFlow) in Output window of VS, I get the messaages:
[08:51:21.6011171] EditorParser: Start full parsing
[08:51:21.6041087] EditorParser: Finished full parsing in 2 ms, 6 errors
Edit: when I open .feature file for first time on opening solution, it parses everything well at first glance. But after 30 seconds, some of steps transit to unrecognized state, as mentioned above.
Edit 1: seems like this part of regex makes problems - \s*(for remote point ""(.*)"")?.
When I put space before open brace (, I get good parsing. But my steps then aren't functioning anymore.
Edit 2: images removed.
Edit 3: I've got mail from Andreas about this topic:
When the regex of a binding is getting to complex the Visual Studio Extension has problems to match them correctly. I fear your regex is already to complex for it.
The runtime should handle it just fine.
From my experience having these kind of checks in the regex make it hard to see then the error at runtime.
I think you only get an exception that the step can't be matched.
If I have such a restricted range of possible values as in your binding, I always have a runtime check that throws an exception if it doesn't pass.
Was working on new functionality in a code file... ManageTime.cs.
Had a bug fix request come in for a bug in the same file.
Used Visual Studio TFS to Suspend My Work.
Fixed bug in ManageTime.cs.
Now What?
Do I Check in ManageTime.cs, then can I resume my shelf set and will it handle merging the shelfset with the new feature code?
Afraid to try without some direction for fear of losing code.
Yes, if your team's policies say that you check in the code after your bug fix, go ahead and do that. If you aren't ready to check in or don't want to check in at this time, but are worried about losing work, you can always create another shelveset just in case (keep the Preserve Pending Changes box checked so you keep your bug fix changes).
Once you are ready, find and unshelve the shelveset. Just like getting the latest version from source control, VS will try to automerge the changes. If there's a conflict that it can't resolve, you'll get the same Resolve Conflicts window that we're used to seeing from time to time to manually resolve the conflicts.
Your assumption appears to be correct. Suspending your code essentially shelves the code along with a few Visual Studio settings such as window location, open files, and similar things. As long as you shelved (suspended) your in process work, then checked in a different bug fix, you should be able to merge with your updated source code once you resume and get latest version.
I'm trying to setup our CI build environment and having an issue.
First, I'm using VS and TFS 2012 so I can't use the *.12.xaml templates since those are for VS/TFS 2013.
Second, right now I'm configured to use just the defaulttemplate.11.xaml. Originally, I was using WebDeploy for the deployment method and that was working great. Since then, our web/server team has re-configured our test environment to use IIS Shared Configuration as well as DFS Replication to keep everything in sync.
Because of that, I'm no longer able to use WebDeploy (I passed this post over to the TFS admins, but they said no).
Is there a place where I can add some msbuild arguments, or a post-build event where I can send a *.cmd file with some arguments so I can get my code copied/deployed?
I've read Hanselman's (and everyone else that copied him) posts/blogs that say "if you're using xcopy, you're doing it wrong, etc...", but I believe in my case I CAN'T use Web Deploy.
Update:
So I thought I found my answer. Since the web deploy doesn't work for me, I found a workflow activity called CopyDirectory that sounded exactly like what I need.
I went through the process of updating my default template to add this additional step to the build process, which by the way, does NOT work very well. After adding the step, saving, etc, the step doesn't ever show up in my build output. I gave up for awhile to go see if I could do this on our Jenkins build server, got some different errors over there so I came back to TFS to make the changes and commit. Since the CI was still setup in TFS (granted, failing), I noticed that a build got kicked off when I made my commit. I decided to watch for awhile and IT FINISHED SUCCESSFULLY! Woah, all right. So I checked through the build logs, and find out that it threw a WARNING saying "failed to copy. Ensure the source directory exists and that you have the appropriate permissions".
Well, since I just entered this value incorrectly, no big deal, just change to the correct BuildDetail.DropLocation, and we should be golden.
WRONG, after building again with my changes to the source and destination values, I come to find out that since I'm trying to deploy my files to a different domain, it still fails.
Oh, and in addition to that, YOU CAN'T PASS CREDENTIALS TO THE COPYDIRECTORY STEP! REALLY! Phew, I found some documentation though, it says "give the tfs build service/account permissions on the domain that you want to copy to. Well, that would be great, if my server team would allow that, but they don't.
Back to square one...(this is going to turn into a blog about me complaining about TFS...)
I believe you can do it using robocopy. You will want to update your build template to include a new InvokeProcess activity. Set the activity's FileName to "RoboCopy" (include the quotes) and it's Arguments to something like the following:
String.Format(" ""{0}"" ""{1}"" /E /R:10 /W:10 /NFL /NDL ", BinariesDirectory, BuildDetail.DropLocation)
Of course changing the robocopy flags to your specific needs.
I don't think you can pass credentials into robocopy either though, so you might still be SOL there.
One possible alternative though is that because your admins won't give the TFS Build User (i.e. tfsservice) permissions on the destination box, you could change the TFS Builds to run as a different User that does have permissions on that box. To do this I believe you just have to log onto your TFS Build machine, go to the Services, find the Visual Studio Team Foundation Build Service Host 2012 (or something similar), and change the Log On As user from tfsservice to whatever user has permissions on the box that you want to publish to. Of course you will also need to give that user permissions to do everything else that the build system needs to do (download source code, etc.).
I'd like to release some updates for a WinForm program, but to date I have simply released an all-new compile. People have to un-install the old version and install the new version.
EDIT: I'm using an auto-generated InstalWizard. It preserves my file strucutre and places the [PrimaryProgramOutput] in a particular directory. I forget what this is called.
I bet there's a way to get around this, but I don't know what it's called. As you may guess, searches for "updates" "new version" "install" and the other obvious things I've tried have generated an impressive number of irrelevant results. >_<
I suspect this process has a particular name, which should point me in the right direction, but if it doesn't please link to a tutorial or something.
I see from the tags you are using C#. Visual Studio can create Setup projects for these kind of tasks. The setup projects als contain a property RemovePreviousVersion, which will remove a previous version if the versioning of your setup is correct and the GUID of the application stays the same.
See this link for more information:
http://www.simple-talk.com/dotnet/visual-studio/updates-to-setup-projects/
ClickOnce deployment is a great solution most of the time...
You can deploy to the web and when ever your users start the application it will check for updates and automatically update the application if there is a new version available.
It can also be configured not to update automatically but only to notify the user that there is a new version available and allow the user to control the update process.