Exploring Power Platform and Beyond: Features, Experiences, Challenges, Solutions all in one place
Hi Folks,
I am extremely happy to share that my blog is 75th in the list of best CRM blogs on the planet ranked by Feed spot.
Thank you for the readers and I will continue to contribute to the community through my blog going ahead.
https://blog.feedspot.com/crm_blogs/
Cheers,
PMDY
Hi,
We recently had to spin up a new Azure VM to run some of our Batch jobs where we need to schedule them to run at specific times in Singapore Time Zone.
But surprisingly when when we VM is provisioned and started…we see the default time zone is set to UTC. Usually by default, every time this would be set to UTC.
In our case, we need to change it to SGT(Singapore Time Zone). The usual way of changing the time zone from Settings–> Time & Language was not possible as this is disabled in our case. But even though it is enabled and changed here, it would be reverted back to UTC when we allocate & deallocate the VM.
So you can use Power Shell Scripts to make this thing work for you. Use below to get all time zones.
Get-TimeZone -ListAvailable
If you want to filter the list, you can do so like
Get-TimeZone -ListAvailable | where ({$_.Id -like “Singapore*”})
Finally for setting the timezone, you can use this cmdlet
Set-TimeZone -Id “Singapore Standard Time”
Hope this helps…
Thank you.
Cheers,
PMDY
Hi Folks,
Recently I came across this problem with one my console applications while working with ADAL library. After debugging for a while, came to know that this DLL referenced had been updated and I strangely note that error popping up.
Then I came to know that there was an assembly binding defined with a different version from the DLL present in the bin folder. So I tried to understand a bit about assembly binding and what assembly binding redirect is all about.
Why are binding redirects needed at all?
Suppose you have application A that references library B, and also library C of version 1.1.2.5. Library B in turn also references library C, but of version 1.1.1.0. Now we have a conflict, because you cannot load different versions of the same assembly at runtime. To resolve this conflict you might use binding redirect, usually to the new version (but can be to the old too). You can do that by adding the following to app.config file of application A, under configuration>runtime>assemblyBinding section (see here for an example of full config file):
<dependentAssembly>
<assemblyIdentity name="C"
publicKeyToken="32ab4ba45e0a69a1"
culture="en-us" />
<bindingRedirect oldVersion="1.1.1.0" newVersion="1.1.2.5" />
</dependentAssembly>You can also specify a range of versions to map:
<bindingRedirect oldVersion="0.0.0.0-1.1.1.0" newVersion="1.1.2.5" /> Now library B, which was compiled with reference to C of version 1.1.1.0 will use C of version 1.1.2.5 at runtime. Of course, you better ensure that library C is backwards compatible or this might lead to unexpected results.
You can redirect any versions of libraries, not just major ones.
If you want to know more about assembly binding, redirects. Please refer to below post.
https://www.codeproject.com/Articles/12215/Assemblies-locating-binding-and-deploying
Finally I was able to resolve this issue by commenting this section in App.config. The fix seem to be easy.
Hope this helps.
Cheers,
PMDY
Reblogged on https://ecellorscrm.wordpress.com/
Off late, I have been receiving lot of requests to explain the nitty-gritty of Power Apps component framework aka PCF.
While there are tons of great articles and videos on PCF are already available, I decided to provide comprehensive PCF beginner guide along with steps to reuse the pre-built controls.
Topics to be covered in this article:
Lets get started and dive in to the details.
What is PCF?
View original post 1,639 more words
ECELLORS CRM Blog 