I'm curious if someone can point me in the right direction here. I support a program that has several possible versions. Some of my customers are always on the latest version, while others seem to only upgrade once every few years. When the software is upgraded, you have to install every subsequent version until you get to the desired new version. So if we have versions 1, 2, 3, 4... all the way to version 10, and someone is upgrading from version 3 to version 9, we'd have to install 4, 5, 6, 7, 8, and then 9. Currently we have to manually run each individual version, so I'm looking at creating a script that will silently install each version and stop at the appropriate spot.
Currently, the only way I know to do this is to write a statement for every single possible combination for the original version and potential version. For example:
If starting version is 3 and ending version is 4
install 4
if starting version is 3 and ending version is 5
install 4
install 5
if starting version is 3 and ending version is 6
install 4
install 5
install 6
(and yes, I'm aware that's not proper powershell code, but I'm hoping you can get the jist of what I'm saying there).
So before I spend way too much time writing figuring out every single possible combination (we have upwards of 40 possible installs), does anyone have a suggestion where I can specify the order that the install files have to be run, then prompt for a starting and stopping point so it will only run between those variables? So for example, if a customer is on version 2 and wants to upgrade to version 8, it would just know to start with installing 3 and install every subsequent install until version 8?
Hoping this makes sense and any assistance would be great!
Given your problem statement and assuming you have enough knowledge to run the installs:
$softwareVersion = Get-Version # I assume you have a way to determine this
:installLoop do {
switch ([version]$softwareVersion) {
[version]'1.0' {
Install-V2
}
<# .. #>
default {
# no version?
break installLoop
}
}
$softwareVersion = Get-Version
} until ([version]$softwareVersion -ge [version]'10.0')
This is just a rough draft. In your case, I would utilize the Switch statement inside a Do loop
$BaseVersion = Get-Version #however you are checking... maybe a function you build
$TargetVersion = 10
Do
{
Switch ($BaseVersion)
{
1
{
Write-Host "Starting upgrade to Version 2"
Install-Version2
}
2
{
Write-Host "Starting upgrade to Version 3"
Install-Version3
}
default
{
Write-Host "No Version Detected"
break
}
}
Start-Sleep -Seconds 60 #Wait 1 min for install to complete before checking again
$Global:Baseversion = Get-Version
}Until($BaseVersion -lt $TargetVersion)
Related
I am using Windows 10 (64 bit) Build 17763. I am writing a program where i need to check for windows version. I know there are different ways of doing this, but the problem is, each method brings out different result, and i am kindof confused why it should be so.
VB.Net
Console.WriteLine(Environment.OSVersion.Version)
Outputs: 6.2.9200 (Major: 6, Minor: 2, Build: 9200)
Powershell
[System.Environment]::OSVersion.Version
Outputs: Outputs: 10.0.17763 (Major: 10, Minor: 0, Build: 17763)
Java
System.out.println(System.getProperty("os.version"));
Outputs: 6.3 (which i guess Major is 6 while minor is 3)
Now, as you can see, all results are not the same. I need to know why, and which result to work with. Thanks
I'm learning Puppet and the biggest frustration I have with the entire paradigm is the try/run/fix development process I'm using to build functional Puppet code. My background is in Java and I'm naturally use to debugging my code to find errors instead of just running the program to see where it bombs making development much faster but I can't seem to find a way to do this using Puppet and Eclipse. I know writing a debugger for Puppet would require some creativity given its nature but I think this is something the community could really benefit from.
I've written debuggers and know the Eclipse SDK but unfortunately it does not map cleanly to the Puppet architecture which is a bit awkward in the sense its runtime stack and execution flow does not happen in natural order as well as the fact the runtime requires a target machine to apply changes on.
I'm curious if the community has done any development work on trying to create some kind of debugger where code can be stepped. To write this I think it would make sense to extend Eclipse with a new Puppet debug configuration type where you specify a target sandbox host to test your code as well as a puppet project in your workspace you want to debug (leveraging existing Gepetto tooling). Then when you start a new Puppet debugging session Eclipse could connect to the remote host, execute puppet apply with some additional debug arguments and somehow provide feedback from the runtime about what line of code is currently being executed.
This still might be awkward but would allow puppet developers to quickly see things like oh duh.. I can't create this directory because the parent path does not exist, wait... why is this if statement not going here like I planned, oh I see here that Puppet is not very clear on single or double quotes or now I see why this fails because this class was not executed first etc. etc.
Instead all we get is a big ugly output on the agent console that yes can give us insight on errors but does not cleanly map exceptions to our code that in my view shows an underlying pain and weakness of Puppet, can you at least give me a stack trace and line number so I know where to look? Nope sorry.
Don't get me wrong, I love how Puppet can make me look very productive throughout the work week when all I'm doing is running Puppet apply on new machines which my manager has not yet figured out but I think for Puppet to really be useful this lack of debugging support is something that needs to be addressed.
Does anyone else feel this pain? - Duncan Krebs
It would be impossible to "step through" puppet code, unless you want to debug against the ruby codebase itself. It's not just that the order of "execution" is unclear, its that the manifest themselves are never executed at a single time. They are actually evaluated in multiple phases throughout execution.
There are ways to simplify finding problems though. The biggest one is writing unit tests using rspec-puppet. It lets you essentially test the compilation phase of puppet, helping you catch errors like circular dependencies, incorrect conditional logic, etc.
There is a new tool called the puppet-debugger which allows you to set breakpoints in your puppet code in order to step through it. So this is no longer "impossible" as it has been available for about 8 months.
You will first need to install the puppet-debugger gem
https://github.com/nwops/puppet-debugger
Then install the debug module, include it in your fixtures or just ensure it is in your module path.
https://forge.puppet.com/nwops/debug
Then just set a breakpoint in your code using debug::break() function.
Ruby Version: 2.0.0
Puppet Version: 4.9.4
Puppet Debugger Version: 0.6.0
Created by: NWOps
Type "exit", "functions", "vars", "krt", "whereami", "facts", "resources", "classes",
"play", "classification", "types", "datatypes", "reset", or "help" for more information.
>> $vars = ['one', 'two', 'three']
=> [
[0] "one",
[1] "two",
[2] "three"
]
>> $vars.each | String $var | {
debug::break()
notify{$var:}
}
From file: puppet_debugger_input20170417-97123-qjwbaj.pp
1: $vars.each | String $var | {
=> 2: debug::break()
3: notify{$var:}
4: }
1:>> $var
=> "one"
2:>> exit
From file: puppet_debugger_input20170417-97123-qjwbaj.pp
1: $vars.each | String $var | {
=> 2: debug::break()
3: notify{$var:}
4: }
1:>> $var
=> "two"
2:>> exit
From file: puppet_debugger_input20170417-97123-qjwbaj.pp
1: $vars.each | String $var | {
=> 2: debug::break()
3: notify{$var:}
4: }
1:>> $var
=> "three"
On windows using Install4j 5.1.12,
This is the scenario:
1). Successfully Install version 1 of app1 in directory v1
2). Try install of version 2 of app1 ( same APPid as above) but check 'No, install into a different directory'.
so that, version 1 remain where it is installed. But, version2 goes to a new directory 'v2'.
Expected : after step 2, I was expecting a new directory called 'v2' created and version2 of the app installed in the new dir 'v2'.
Actual: After step 2, version2 installed on top of version1 in dir 'v1' and no dir 'v2' created.
This used to work in old versions of our app installer. I compared it to the sample apps 'hello' of Install4j 5.1.12. Installer/update options has 'Regular Installer'/ Detect previous installation dir selected in the same way as the 'sample' apps.
Wondering what else to check .
Thanks , let me know if you need some more info.
Thanks Ingo, yes there was a condition the was using a wrong context setting ,
instead of :
context.getBooleanVariable("sys.confirmedUpdateInstallation") == true
it was :
context.isUpdateInstallation() == true
Thanks for the hint and further support.
-G
I met an annoying problem when i try to upgrade my new version app 1.0.0.1 to my sharepoint 2013 server.
The detail steps I did,
1, Create a development site in sp 2013.
2, Create a sharepoint-host app project in visualstudio.
3, using "deploy" to deploy the app to sp2013.
4, Now the version number is 1.0.0.0, and everything looks good.
5, I made some changes and set a new version number at AppManifest.xml,1.0.0.1.
6, using
$spapp = Import-SPAppPackage -Path .\DevCore.AppCalendar.app -Site [http://sp-ss2013/sites/testapp] -Source ([microsoft.sharepoint.administration.spappsource]::ObjectModel)
$instance = Get-SPAppInstance -AppInstanceId 4c472c85-2759-489f-8435-c6cc7b11eb91 -Site [http://sp-ss2013/sites/testapp]
Update-SPAppInstance -Identity $instance -App $spapp
to update the appinstance.
7, after the update process has been done, check the app detail, it is the new version number.
8, But all stuff in app look the same, the change doest work at all
I tried iisrest but it turns out the same result.
Really need help, otherwise I have to reinstall the app......
/Dong
I am making a change to Perl/Tk for an application that has its own resident Perl and modules installation (so we can drop the app in and go).
I've found a problem I am experiencing that I just stumbled on what seems to be the patch I need here: http://osdir.com/ml/lang.perl.tk/2004-10/msg00030.html
Bug confirmed. Here's the patch against Tk804.027:
--- Tk-804.027/pTk/mTk/generic/tkEntry.c Sat Mar 20 19:54:48 2004
+++ Tk-804.027-perl5.8.3d/pTk/mTk/generic/tkEntry.c Tue Oct 19 22:50:31 2004
## -3478,6 +3478,18 ##
Tcl_DStringFree(&script);
#else
+ switch (type) {
+ case VALIDATE_INSERT:
+ type = 1;
+ break;
+ case VALIDATE_DELETE:
+ type = 0;
+ break;
+ default:
+ type = -1;
+ break;
+ }
+
code = LangDoCallback(entryPtr->interp, entryPtr->validateCmd, 1, 5, "%s
%s %s %d %d",
new, change, entryPtr->string, index, type);
if (code != TCL_OK && code != TCL_RETURN) {
Regards,
Slaven
I'd like to apply this patch or if there is a newer version of the Perl/Tk module I can upgrade to that includes this patch already that doesn't require I change the version of Perl, do that.
Here is what I can find from the installation for this app:
perl -v = 5.8.4
$Tk::version = '8.4'
$Tk::patchlevel = '8.4'
$Tk::VERSION = '804.027'
So..
1a) if there is a newer Tk VERSION that includes the patch in the link above, how do I upgrade just that module in the specific Perl installation location for this app?
1b) how do I know if that upgrade is compatible with 5.8.4 of Perl (I don't want to upgrade perl at this point)
2) if not, how do I apply that patch defined in that link?
First, check CPAN to see what the current version of Tk is. At the time of this response, it's 804.028, so it's possible that your bug has been fixed. You can check the Tk bug queue to see the state of reported bugs, although I don't know if your specific one was ever entered in the queue. You can also check the Changes file for the release to see if your issue is mentioned there.
If you don't see anything specific, you might note that the author of your quoted message is the maintainer of Tk, so it's likely that the patch has been applied. :)
Tk is a distribution. You can't upgrade individual modules.
Check the Perl/Platform Version Matrix to see which versions of Tk work on which platforms and under what versions of Perl.
If you absolutely must apply just this one change, download the source for the version of Tk you're using, apply the patch, and rebuild it.