Starting to work with the graph API (specifically the .Net SDK), and while the "Drive" object indicates whether the root is "personal", "business" or a SP library, I don't see anywhere to find the explicit capabilities of a drive or driveitem. Especially as it pertains to versioning.
How do you determine whether a drive or folder or specific driveitem allows versioning?
The DriveItem class has a Versions property to identify if there are versions of a file. That version field is nullable. I'm not sure if a null value indicates that versioning is not enabled or if there are no previous versions.
Related
I am porting legacy code that is using the Microsoft.TeamFoundation.Client libraries to .NET 6 using the new client libraries (here).
I cannot work out what I need to do to mimic a simple "Get" operation.
With the old libraries, a project collection is created, a workspace mapped and then a full recursive get could be called for any path.
With the new libraries, the closest I can get is to obtain a TfvcHttpClient and call GetItemsAsync. But I can only specify one level of recursion and the call doesn't download the files.
I have been all over the client samples here but they only show how to enumerate through a list of items. I can't see anything that actually gets any source? The repo has been marked as read only now so I can't ask questions there.
Is there no way with the new client libraries of doing what was possible before i.e. the "get" of a source control folder with full recursion?
Can anyone point me in the direction of a sample that performs actual retrieval of source?
The generate multiple files option is not available in the 0.13.0 Settings UI but there is an entry in the ConnectedService.json settings file.
I tried editing the settings file manually and forcing an update but it did not work.
Has this feature been deprecated or is it just broken? I also noticed the custom namespace option did not seem to work either.
This is what shows up in the online documents:
https://learn.microsoft.com/en-us/odata/connectedservice/generating-multiple-files
Another doc shows a different UI...
What my VS 2017/2019 extension shows:
The latest version seems to be version 0.13, the feature seems to be introduced in the OData Connected Service 0.9.1 Release.
The "Generate Multiple Files" option is only available when you're targeting an OData v4 service. This also applies to a few other settings as well. Confirm whether you're targeting an OData v1, v2 or v3 service, if that's the case, that would explain why you're seeing different available options. The docs should be updated to reflect this.
I need to know the user name and other data of the logged-in user in a project organized using BPLs. That is, how and where do I need to declare the user object and its creation, and how to get access to that object when a package is loaded at runtime? I don't have enough experience working with packages.
In a regular app, for the programmer there is no difference between using runtime packages or all in a single exe
You can change the project to go with runtime packages or not, and your code won't change at all
That changes when you make a modular app that loads BPL modules on demand, chosing at runtime if a given module will be load, and doing it dynamically (ex. app made with a plugin-architecture in mind), then you need to design your own strategy to handle that
Myself, I work in that second way, and I do have some main modules wich give services to the "plugins", so when they are loaded, they do register themselves with the system: user control, navigation, whatever
There is nothing special to use objects in a package. You just add the unit name where the object is defined to the uses clause of the unit where the object is to be used.
You should really read the documentation on this topic. The you may ask more questions to clarify things you don't understand.
I ran into a situation where two machines both had "microsoft.teamfoundation.testmanagement.client.dll" in the GAC with the same version and public key. They differed in the content they contained though. The newer one had additional classes (e.g. BuildCoverage). Why would the content of the dll change while the version and public key stay the same? Is this common practice?
I don't know if it's common practice, but there are times when the AssemblyVersion (for Strong naming) isn't incremented during an "in-place" minor update to a GAC'd assembly to hot-fix a bug. Check the actual File Version by navigating to the file via command prompt and then checking it's properties. See if there's a difference between the files there. That should indicate if the actual build number is different between them. I bet a small VS hotfix has been applied to one and not another.
It's very normal to update an AssemblyFileVersion but not update the AssemblyVersion attribute. This is how hotfixes for .NET get shipped for example. The key is to test the hell out of the assembly to make sure it's completly backwards compatible to prevent DLL hell.
How source code is stored in SQL server for TFS2010.Is it possible to see it by digging the Database?
Versions of checked-in files are indeed stored in the database, which is basically just a simple blob store that contains a mix of the entire version controlled files as well as "deltas" between them.
That is to say that the server will occasionally store the differences between two versions of the files using a binary delta algorithm. For example, for a file $/Project/File.txt, version 1 may be stored intact but version 2 may be stored as the delta from version 1. When a client requests version 2 of $/Project/File.txt, the file may be reassembled from deltas before delivery.
The database is intended to be treated as an opaque data store and is generally not supported. In order to interact with your version control programmatically, it is intended that you would use the very rich APIs that are available for communicating with Team Foundation Server, either from .NET
or from Java.