Is it possible to download Beta releases and RC releases of Identity Server? I saw 5.1 went Beta last week and there are quite a few things I'd like to check out.
If there isn't a download, are the build / source download procedures changing much since it's a different carbon and much has moved into Github...?
Turns out if you choose the "Releases" tab on the Github project, you can download a built copy, plus bundled source for that tag...
https://github.com/wso2/product-is/releases
Related
Since the update before last to AWS Toolkit, when running Visual Studio 2022 with AWS Toolkit installed and enabled, the entire PC grinds to crawl.
Specifically, physical memory use shoots up to 99%, there's a huge amount of continuous disk activity and CPU use rises to around 50%. This renders the entire system completely unusable (think, two minute delay between clicking and something happening). Oddly, nothing appears in the process list in Task Manager that accounts for either the levels of memory or CPU use. It feels like a monumental memory leak but really I've no idea what's going on.
I've tried completely uninstalling and reinstalling VS and uninstalling, deleting the AWS Toolkit folder in "Users...etc." and reinstalling the Toolkit. Everything is fully up-to-date.
As I say, this has happened since the update before last. It's strange that it isn't mentioned anywhere that I can find on the internet and it's difficult to imagine that such a serious issue would only happen to me.
So, has this happened to anyone else and does anyone have a fix? I wanted to raise a support case on AWS Console but I only have a basic account so am unable to do so.
This issue has been resolved (see https://github.com/aws/aws-toolkit-visual-studio/issues/314#issuecomment-1401060605 for more details).
The system in question is running Windows 7. At some point .NET 7 was installed onto it (possibly as a result of a Visual Studio update). .NET 7 does not support Windows 7, and dotnet publish commands started to produce internal errors, and is taking a long time to complete. The AWS Toolkit's Lambda publishing features are built on top of the dotnet CLI commands, which is how the degradation was noticed.
This can be mitigated by installing an older version of .NET (like .NET 6) and telling the dotnet tooling to use a specific version of .NET instead of the latest detected version.
From https://learn.microsoft.com/en-us/dotnet/core/tools/global-json:
The global.json file allows you to define which .NET SDK version is used when you run .NET CLI commands. Selecting the .NET SDK version is independent from specifying the runtime version a project targets. The .NET SDK version indicates which version of the .NET CLI is used.
Add a global.json file to the same folder as your project or solution with the contents shown below, referring to the .NET SDK version you want to use (the example below uses 6.0.300)
{
"sdk": {
"version": "6.0.300"
}
}
I couldn't stomach purchasing the $150 for GCP's support service for this one question. I'm just looking to understand the schedule for Cloud Build Node.js versions. It's still stuck on Node.js v10.10 and my projects are starting to require higher versions to build. According to Cloud Build's changelog, I don't believe the Node.js version has updated in years. Any ideas?
As per the official Github repository:
Our client libraries follow the Node.js release schedule. Libraries are compatible with all current active and maintenance versions of Node.js.
So, this means it should work with Node.js 12 and the updates should be more constant. In addition to that, in here, it says that if you are using a Cloud Build config file, you can use Node.js 12, so the Node.js' latest version should be compatible with Cloud Build.
To summarize, by the repository, it should follow Node.js schedule. However, in case you think this is not occurring, I would recommend you to raise a bug on the Google's Issue Tracker - it's free, by the way - so they can assess this.
I will be getting a new machine soon but I am curious if my old VS extensions will be automatically installed - I don't want this as I want a fresh system to reconfigure
It is controlled by Roaming Extension Manager. It shows all extensions you have on another machine, but doesn't automatically download them.
If you dont want your extensions to follow you to your new machine. Your best bet is to disable Automatic updates before you log out of your old machine, as desribed on this page.
Once youve signed into your account on your new machine you can check your list of extensions. If it is empty, then install what you need. If it is showing your extensions from your old account then delete at will.
The Sitecore documentation provides some pretty clear instructions on how to configure a Sitecore instance as a processing server:
https://doc.sitecore.net/sitecore_experience_platform/xdb_configuration/configure_a_processing_server
However, many of those steps require enabling/disabling of files manually on the installed server. Has anybody seen or built a patch file (similar to SwitchMasterToWeb) that can disable/enable the appropriate functionality as a patch? I would rather not touch the default Sitecore install and instead rely on automated deployment of configuration patches.
I haven't seen this as a patch and not sure if its possible to do this with just one patch (would love to be proved wrong), but for something like this I've used a Powershell script.
I set up Octopus Deploy to run a Powershell script step after deploy to disable files and change settings if patch files can't do the job.
I can highly recommend the Powercore tools for this kind of thing.
https://github.com/adoprog/Sitecore-PowerCore/tree/master/Framework/ConfigUtils
If anybody else winds up looking for this, I've posted some work up on GitHub for patch files for a variety of versions for 8.0:
https://github.com/jst-cyr/Sitecore-Role-Configs
The patches there will do the 'disable/enable/change' for authoring, delivery, or processing. I don't have one for the reporting server.
Sitecore has evaluated POC for same. At this point of time applciable for Sitecore CMS 8.1 rev. 160302 (Update-2). See here-
https://github.com/Sitecore/Sitecore-Configuration-Roles
We have an MSI to install windows service on client machine.
Windows service calls the web service of our server to perform operations.
Initially both the MSI and web service were built using .NET 2.0 framework.
Last quarter we upgraded our systems to .NET 4.0. Though our web service is still ASP.NET i.e. asmx (and not WCF). Also I did set framework 4.0 as the prerequisite for MSI to install.
One of our clients reported this issue:
Client was using .NET framework 2.0, and had the older version of MSI installed in his system.
When he tried to installed the .NET framework 4.0 version of the MSI, was prompted to install framework 4.0 (because of the prerequisite). Once the framework installation finished, he tried to install the MSI and got this error. Can someone please guide me to the resolution. I can provide details if needed.
EDIT 1:
On more research, I found it is my AppName.installstate file. Uninstall removes this file, but upgrade does not do it. The file is lying in the install directory. On a closer look I can see "http://schemas.xmlsoap.org/soap/envelope/:Envelope" in the file contents. Any pointer would be greatly appreciated.
EDIT 2:
Custom action Install creates AppName.installstate file and custom action Uninstall deletes the file. In my case, I am doing an MSI upgrade which does not do anything to this file. When I compared the installstate file from 2.0 and 4.0 (both installed manually), I could see a huge difference in the XML syntax, schema and contents, the reason, I am getting serialization error. Now I need to know why AppName.installstate is not getting overwritten when upgraded. Doing lot of google, but landing nowhere.
Looked at MSI install log, but no useful information.
Eureka !!!!
I found solution to my problem.
Root cause of the problem:
MSI generates an XML file during installation (application_name.installstate), which stores information MSI uses during install, uninstall, rollback. The format of this XML file is completely different between .NET 2.0 and .NET 4.0 i.e. MSI developed using VS2005 and VS2010.
Because 4.0 frmaework is not able to understand the file generated by Old Framework version (2.0), we are getting the error saying “Not able to serialize the Type of the Installstate file”.
Though there is no documentation available online for this, there is this discussion I found > http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/bedbb8bd-dad5-4bcb-a87a-ac69386669b4/
Solution I tried (I would call it work-around):
During installation of the New version, I am explicitly replacing the old XML file with the new format (4.0). i.e I included application_Name.installstate file (generated by new version) in my package, so it overwrote the old file while upgrade.
MSI got installed without any error and is running successfully.
Reply here if anybody needs detail on both problem and solution.
This error message has nothing to do with the installer per the 1001 error message. The problem is fully inside your service.
Your service's OnStart method should be doing nothing but spinning up a background process and returning success start to the service control manager as quickly as possible. There shouldn't be any long running code in that critical path as the SCM will only wait so long before assuming there was an error starting the service.
Refactor your service to run the job on another thread and the install will successfully install. From there you can focus on the real problem of what's going on in your DeSerialization process.