If upgrade 'play-services-games:22.0.1' to 'play-services-games:23.0.0'
I get an error saying 'cannot find symbol requestScopes(Games.SCOPE_GAMES)'
Why can't I check SCOPE_GAMES(or SCOPE_GAMES_LITE) in the new version?
GoogleSignInOptions gso = new GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_GAMES_SIGN_IN)
.requestScopes(Games.SCOPE_GAMES)
.build();
mGoogleSignInClient = GoogleSignIn.getClient(parentContext, gso);
I believe that the correct approach is to replace Games.SCOPE_GAMES with the URI as defined in Scopes to create a scope:
[...]
.requestScopes(Scope(Scopes.GAMES))
.build()
It took me a bit to find the equivalent for Games.SCOPE_GAMES_SNAPSHOTS; as the data is stored in the user's Drive app's folder, the scope to use is:
[...]
.requestScopes(Scope(Scopes.DRIVE_APPFOLDER))
[...]
Related
.NET MAUI App,
I am trying to get a list of Children from Root folder on Drive... I get this error in edition/compile time, when I use a snippet of code from MS Learn:
'DriveRequestBuilder' does not contain a definition for 'Root' and no accessible extension method 'Root' accepting a first argument of type 'DriveRequestBuilder' could be found (are you missing a using directive or an assembly reference?)
I just cloned a sample project developed by microsoft staff and inserted a snippet of code from MS Learn.
Pls, get the entire project with the error here:
https://github.com/leoderja/DriveRequestBuilder_RootNotDefined.git
The error is in:
MauiAppBasic.csproj project ->
MSALClient folder ->
MSGraphHelper.cs file ->
TestRootChildrenAsync method
Using Microsoft.Graph version 5.0.0-rc.1
EDITION: Here a minimal example:
using Microsoft.Graph;
GraphServiceClient graphClient = new GraphServiceClient(new HttpClient());
var children = await graphClient.Me.Drive.Root.Children.Request().GetAsync();
The problem was Microsoft.Graph v5.00 rc1. When I set v4.50 the errors disappeared. I hope that Microsoft staff update the documentation with the changes when final release of v5 is available.
Since version 5 the Root is accessible through Drives[userDriveId] but not through Me.Drive
var children = await client.Drives[userDriveId].Root.Children.GetAsync();
If you don't know the user's drive id you need to call Me.Drive.
var driveItem = await client.Me.Drive.GetAsync();
var children = await client.Drives[driveItem.Id].Root.Children.GetAsync();
I am trying to update an item on podio through their Java API. It worked fine for a while, but now, but after some time it gave me this error:
APIException [status=Conflict, error=conflict, description=A newer version exists , parameters=null]
Right now, if I sent another request to update the item that had this error, it will return the same error. I don't understand.
What does this error mean? and how do i solve it? Is that item going to give me the same error error forever?
Here's a snippet of my code:
List<FieldValuesUpdate> fields = new ArrayList<>();
String valueSubId = "value";
fields.add(new FieldValuesUpdate(1234567890, valueSubId, something.getName()));
fields.add(new FieldValuesUpdate(1234567891, valueSubId, something.getCode()));
fields.add(new FieldValuesUpdate(1234567892, valueSubId, something.getAddress()));
fields.add(new FieldValuesUpdate(1234567893, valueSubId, something.getStatus()));
ItemUpdate itemUpdate = new ItemUpdate(null, fields);
int itemId = 123444;
podioItemApi.updateItem(itemId, itemUpdate, true, false);
Looks like you are trying to create item and adding fields but your app is updated and maybe some of fields doesn't exist anymore.
Please send full http request and response for your call, that will definitely help understanding what's happening.
Had the same issue as well.
And as mentioned earlier, it has to do with the revision provided. Using the Java API, the revision is set automatically. Therefore, if an entry has been updated manually it will have a revision of >0, while example by JayDoe will leave it at 0 which is the conflict.
I decided not to hack the API, but use it the way an update workflow is meant to be used. reading the entry first, then setting its revision into the ItemUpdate object.
I am using NodaTime's LocalDate in RavenDB index.
Here is an example of the index:
public class TaskIndex : AbstractIndexCreationTask<ScheduleTask>
{
public TaskIndex()
{
Map = tasks => from task in tasks
select new
{
task.Name,
PlannedStartDate = task.PlannedStartDate.AsLocalDate().Resolve(),
PlannedDueDate = task.PlannedDueDate.AsLocalDate().Resolve()
};
Index(x => x.Name, FieldIndexing.Analyzed);
Store(x => x.Name, FieldStorage.Yes);
TermVector(x => x.Name, FieldTermVector.WithPositionsAndOffsets);
}
}
I installed RavenDB-NodaTime bundle as described here.
Here is a piece of code I use to install index:
var assembly = AppDomain.CurrentDomain.Load(new AssemblyName
{
Name = "cs.Scheduling"
});
var catalog = new AssemblyCatalog(assembly);
var provider = new CompositionContainer(catalog);
var commands = documentStore.DatabaseCommands.ForDatabase(dbName);
IndexCreation.CreateIndexes(provider, commands, documentStore.Conventions);
documentStore is configured with default database, but then I use it to install index to different (tenant) database name of which comes in dbName.
During the installation of the index I got an exception: The name 'NodaTimeField' does not exist in the current context.
I have one default database which is completely different from database I try to install index for. So basically the case is similar to one described here but I am using standalone version of RavenDB server.
I tried to find out how I can do suggested there but was not able to do that:
embeddableDocumentStore.ServerIfEmbedded.Options.DatabaseLandlord.SetupTenantConfiguration += configuration =>
{
configuration.Catalog.Catalogs.Add(new TypeCatalog(typeof(DeleteOnConflict)));
configuration.Catalog.Catalogs.Add(new TypeCatalog(typeof(PutOnConflict)));
};
Version of RavenDB I am using is 2.5.2956.
RavenDB.Client.NodaTime - 2.5.10.
Hope for your help. Thanks.
In my case that was a very silly mistake. When I was installing RavenDB server some time ago I installed it into non-default destination. Later some RavenDB updates were installed into default destination (i.e. \Program Files (x86)\RavenDB). And when I was installing RavenDB-NodaTime bundle I put it into incorrect destination (\Program Files (x86)\RavenDB).
After detecting this issue and configuring RavenDB server in my correct destination properly an error described in the heading has gone away.
Hope this answer can help somebody else.
P.S. Later there was a deserialization error during reading data from db (RavenDB was not aware of how to deserialize date from string in "yyyy-MM-dd" format to LocalDate object) which I fixed by calling store.ConfigureForNodaTime(DateTimeZoneProviders.Tzdb); after store.Initialize(); call as Steven suggested in his answer.
I believe the answer is that your tenant database does not have the bundle "activated" Your database document (under settings in Raven 3) should have something like
"Raven/ActiveBundles": "Encryption;Compression;NodaTime"
Also you must call
store.ConfigureForNodaTime(DateTimeZoneProviders.Tzdb);
I call this after store.Initialize(). Once you do both of these things, you may have to fix existing data by re-saving your documents (not sure if there is another way). New data will be properly stored like '2016-2-3' format which should make your index return data.
1) Earlier this week I was able to create defects and testcases using the Create method, which took 2 arguments at the time (a string and the DynamicJsonObject). However now, it needs three. I understand that one of these is now the workspace reference. How do I go about getting the workspace reference? For creating defects and testcases, I am using an empty string, and this seems to be working correctly for me. Is this to be expected?
2) For creating test case results, I am having a bit of trouble.
DynamicJsonObject newTCResult = new DynamicJsonObject();
newTCResult["Date"] = DateTime.Now.ToString("yyyyMMdd");
newTCResult["TestCase"] = "/testcase/11271454106";
newTCResult["Notes"] = "test";
newTCResult["Build"] = "13.1.0.90";
newTCResult["Verdict"] = "Pass";
CreateResult cr = restApi.Create(" ", "TestCaseResult", newTCResult);
As of right now, absolutely nothing is happening when I run this. I was able to do this successfully earlier this week (when I was able to use the Create method with two arguments). I feel that the problem is because I don't have a valid workspace reference. I followed the suggestion of another user in a similar question prior to this which worked for earlier, however now I am having this problem.
I was finally able to resolve this. It appears that the date field needs to be converted to UTC, so my code now looks something like this
newTCResult["Date"] = DateTime.UtcNow.ToString("o");
After making that small change results were working correctly.
It's somewhat surprising that Creates on Stories or Defects work with an empty string for a Workspace ref, although I suspect that on the server-side, the Webservices API is just using Default Workspace for the User of concern.
Either way, here's how you can get a ref to the Workspace of interest:
String myWorkspaceName = "My Workspace";
// Get a Reference to Target Workspace
Request workspaceRequest = new Request("workspace");
workspaceRequest.Fetch = new List<string>()
{
"Name",
"ObjectID"
};
workspaceRequest.Query = new Query("Name", Query.Operator.Equals, myWorkspaceName);
QueryResult workspaceQueryResults = restApi.Query(workspaceRequest);
var targetWorkspace = workspaceQueryResults.Results.First();
Console.WriteLine("Found Target Workspace: " + targetWorkspace["Name"]);
String workspaceRef = targetWorkspace["_ref"];
You can then use workspaceRef in your call to restApi.Create().
I need to embed some resource in a pure compiled dll written in php using phalanger.
These are txt files tha I set in visual studio as "Embedded Resource".
My problem is that I cannot use the Assembly class to get the resource using GetManifestResourceStream.
I tried code like this:
use System\Reflection\Assembly
$asm = Assembly::GetExecutingAssembly(); //this gives me mscorlib instead of my dll
$str = $asm->GetManifestResourceStream("name");
My question is: how do I get access to embedded resources in phalanger?
Many thanks
I'm not sure, why Assembly::GetExecutingAssembly() returns an incorrect value. Anyway to workaround the $asm value, use following code:
$MyType = CLRTypeOf MyProgram;
$asm = $MyType->Assembly;
Then you can access embedded resources as you posted
$asm->GetManifestResourceStream("TextFile1.txt");
or you can include standard resource file (.resx) into your project, and use \System\Resources\ResourceManager
$this->manager = new \System\Resources\ResourceManager("",$asm);
$this->manager->GetObject("String1",null);
Just note, currently there can be just one .resx within Phalanger project
This question is old, but the part of the Phalanger code (Php.Core.Emit.AddResourceFile() method) responsible for this hasn't changed since this was asked. I faced the same problem and solved it in (almost) non-hacky way. You have to provide alternative name (/res:/path/to/filename,alternative-name) for this to work though.
$asm = clr_typeof('self')->Assembly;
$resourceStream = $asm->GetManifestResourceStream("filename");
$reader = new \System\Resources\ResourceReader($resourceStream);
$type = $data = null;
$reader->GetResourceData("alternative-name", $type, $data);
// and still there are 4 excess bytes
// representing the length of the resource
$data = \substr($data, 4);
$stream = new IO\MemoryStream($data);
// after this $stream is usable as you would expect
Straightforward GetManifestResourceStream() (as suggested by Jakub) does not work because Phalanger does not use System.Reflection.Emit.ModuleBuilder.DefineManifestResource() (like I think it should when supplied with unrecognized file format). It uses ModuleBuilder.DefineResource() which returns ResourceWriter instead, that only really suited for .resources files. And this is what dictates the requirement to use ResourceReader when you need to read your resource.
Note: This answer applies to Phalanger master branch at the time of writing and prior versions since circa 2011. Noted because it looks like a bug (especially the need to use both original and alternative names).