I am writing/testing a server side plug-in and am looking to derive if this is running on our development or production TFS instance to allow me to drive a slightly different process (e.g. add some obvious text to any email subjects that it sends out to ensure that people know it has derived from the development instance).
There is a "IsProduction" property that I can access via the requestContext variable (IVSSRequestContext.ServiceHost.IsProduction - was previously TeamFoundationRequestContext.TeamFoundationServicehost.IsProduction before TFS2015), but this property is set to true in both instances.
Does anyone know if/should this can be used for that purpose and if so, how it can be set as I can't find any documentation online and can't see anything obvious in the TFS Admin Console.
No, but I suggest using a global Environment variable (e.g. IsDevelopment).
Another option is to get the server URL (see code snippet) and use it to determine the environment, but I think it is less safe.
private Uri GetCollectionUriFromContext(IVssRequestContext requestContext)
{
ILocationService service = requestContext.GetService<ILocationService>();
return service.GetSelfReferenceUri(requestContext,
service.GetDefaultAccessMapping(requestContext));
}
Related
I'm trying to figure out how to use the recommended approach from Microsoft and use the Installation Model to handle registrations.
I want to be able to get some information about the installations that should have been saved and I see that there are two methods that could be useful
GetInstallation(string installationId) and GetInstallationAsync(string installationId)
Problem is that when making at call to any of them I never get a response back. I can't figure out what I might be doing wrong.
Here's the answer from a similar question (that still holds true as of Nov 2016):
... there's no way to get all installations for a hub. In the future, the
product team is planning to add this feature to the installations
model, but it will work in a different way. Instead of making it a
runtime operation, you'll provide your storage [account] connection string and
you'll get a blob with everything associated with the hub.
My group is getting into web services for the first time. What is the usual way to control versioning issues with web services and clients? We're generating our services and clients using in IBM's RAD using the wizards it presents. The services and clients work well enough, but we're wondering how managing these will become a task going forward.
-If a service changes, and it's interface doesn't change I presume older clients would never know the difference and would work fine.
-If a service changes to add a new property to a parameter, would older clients work with it if they didn't need to set that value?
-How do people handle version control of web services as they grow in number and the number of apps using their clients grows? What is best practice on this sort of thing?
There are two types of versioning that we use. One that is visible to clients (public) and one that isn't (private). This comes from (what you already touched upon) whether clients are affected or not.
If clients are affect by, for example change in XSD Schema definitions or functionality of the WS changes in such way that clients must also modify their end, we change the public version. We increment the version number in WS context root, which means that it will have different URL than the previous version. Also make sure that the code archive, in our case they are war, have also the public version, as not to overwrite the previous deployment.
For example our WS called foo is in public version 2. Its URL is http://ourserver:8000/foo_2 and war file is called foo_2. We modified our XSD Schema, so the clients must react to the change. We update the version and now URL is http://ourserver:8000/foo_3 and war file is called foo_3. The previous version still exists, while clients can slowly transition to the new version.
If the change does not force any action from clients, then we call this private versioning. This usually shows up, in combination with public version, as a part of a project name. Using previous example, we have a WS foo, with private version 5 and public 2. Our project for this service is called WS_foo_2_5. We now change the order in which we store incoming data. This does not effect the clients, so we change the private version. In effect we have project WS_foo_2_6. We create a code archive from it called foo_2 and deploy it with URL set to http://ourserver:8000/foo_2. This way we modified the version, without changing anything from clients POV.
I am trying to figure out the best way to mitigate this situation. My project team consists of 3 developers each with their own instances of SSRS installed. We have 2 external SSRS servers that we must push updates to in order for the customer to review and for us to test and there is a 3rd external server coming online that will not be administered by us.
I have been trying to find a way to set the Shared Data Source to the current environment regardless of the system it is on. I had thought that just a common naming convention for the ReportServer address would be fine, but we've already found them to be inconsistent on the production and test servers. My next attempt was to specify an ODBC connection and let each person create a system DSN with connection information, but after an entire day of messing with it and continually getting errors, I'm not convinced it's the way to go. ( The most recent error being "The specified DSN contains an architecture mismatch between the Driver and Application" ). I have tried going through Windows ODBC DSN msc to create the DSN and I have tried using Report Builder 3.0 to create one and neither seem to work.
So I guess at this point I just have to ask, is there a best practice for going about this? I'd like to do local development and testing via the "Run" button inside Report Builder and then I'd just like to upload the file to the Report Manager and have it work regardless of the URL for the Report Server.
If the properties (connectionstring, etc) for shared data sources don't change much on your servers, the following may work for you: in the properties for your project set OverwriteDataSources = False for the appropriate configurations. Set it to true only temporarily to change the data source, if needed.
That way any dev can safely deploy to the servers, without affecting the data source, even if (s)he locally changed something (e.g. the connection string) to match a personal environment.
Not an optimal solution, but relatively easy to set up.
I'm creating a iOS app that requires the user to log in at startup, and then uses those credentials to query 4-5 different services on a server over the course of the session.
The server (xyz) it self doesn't accept the credentials, but if the services that it provides are queried then they get accepted. For example https://xyz/service1 works, https://xyz doesn't.
Now what I'm wondering about is if there is anything that stands in the way of creating 4-5 NSURLProtectionSpace's at log in, one for each service on the server, and then use the corresponding protection space when use each service?
Or is there a better way of implementing something that could work in this situation?
All help would be appreciated.
Turns out that there is nothing that stands in the way of creating multiple NSURLProtectionSpace's since each is created for a separate url.
I'm writing a mock of a third-party web service to allow us to develop and test our application.
I have a requirement to emulate functionality that allows the user to submit data, and then at some point in the future retrieve the results of processing on the service. What I need to do is persist the submitted data somewhere, and retrieve it later (not in the same session). What I'd like to do is persist the data to a database (simplest solution), but the environment that will host the mock service doesn't allow for that.
I tried using IsolatedStorage (application-scoped), but this doesn't seem to work in my instance. (I'm using the following to get the store...
IsolatedStorageFile.GetStore(IsolatedStorageScope.Application |
IsolatedStorageScope.Assembly, null, null);
I guess my question is (bearing in mind the fact that I understand the limitations of IsolatedStorage) how would I go about getting this to work? If there is no consistent way to do it, I guess I'll have to fall back to persisting to a specific file location on the filesystem, and all the pain of permission setting that entails in our environment.
Self-answer.
For the pruposes of dev and test, I realised it would be easiest to limit the lifetime of the persisted objects, and use
HttpRuntime.Cache
to store the objects. This has just enough flexibility to cope with my situation.