Sharepoint 2013 App upgrade issue - deployment

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

Related

Assistance with Script To Automate Upgrades with PowerShell

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)

Get-AzureRMSubscription produces error after login with login-azurermaccount

I am trying to use get-azurermsubscription to get a list of available subscriptions in order to select one of five prior to running set-azurermcontext. I am getting the error:
Method not found: 'Microsoft.Azure.Subscriptions.Models.SubscriptionListResult'
get-azurermcontext displays a valid tenatant id and valid subscription id, but of course does not display all of the subscriptions.
I downloaded the March 2015 Powershell installer to make sure everything was up to date, but have the same issues.
Just upgraded to VisualStudio 2015 update 2 and powershell v5. Have another machine with a similar configuration that works fine.
What should I do to fix this issue?
I can't add a comment so doing it this way instead. On July 12 2016 AzureRM module received and update to version 1.6.0. I confirmed the cmd Get-AzureRMSubsctiption works from a Windows 10 machine.

VSO NuGet Publisher Build Step Fails

I am using Visual Studio Online - Package Manager Preview, along with the new build system. The package manager preview adds a number of build steps, including a "NuGet Publisher" step, which should push packages to the private feed hosted by Visual Studio Online.
Now the documentation is a little out of step here. As is the documentation on auth and personal access tokens. There are some indications that you shouldn't need auth between VSO and the Package Manager as long as you have permissions set up (the build service account has permissions to the service endpoint and to the package manager extension). The actual build step asks you to select from your list of Service Endpoints, so that is what I have attempted.
When I place no credentials on the Service Endpoint, I get the error:
Server Key must be set, set the password on the generic service
When I attempt to place the API key against the Service Endpoint it seems to be discarded on save... and the error changes to:
2015-11-18T08:35:24.5678951Z Invoking nuget with push C:\a\1\s\EventViewer\bin\Release\Project.Name.1.1.12.0.nupkg -s https://example.pkgs.visualstudio.com/DefaultCollection/_packaging/example/nuget/v3/index.json usfusmx4ez6mlfqwpp2abzc7e37denfcp7bxsep2hqij3tp4qwvq on C:\a\1\s\EventViewer\bin\Release\Project.Name.1.1.12.0.nupkg
2015-11-18T08:35:24.5688946Z C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\agent\worker\tools\NuGet.exe push C:\a\1\s\EventViewer\bin\Release\Project.Name.1.1.12.0.nupkg -s https://example.pkgs.visualstudio.com/DefaultCollection/_packaging/Example/nuget/v3/index.json usfusmx4ez6mlfqwpp2abzc7e37denfcp7bxsep2hqij3tp4qwvq
2015-11-18T08:35:25.3467312Z Please provide credentials for: https://example.pkgs.visualstudio.com/DefaultCollection/_packaging/Example/nuget/v3/index.json
2015-11-18T08:35:25.3667189Z ##[error]Object reference not set to an instance of an object.
2015-11-18T08:35:25.3677179Z UserName: Password:
2015-11-18T08:35:25.4647059Z ##[error]Unexpected exit code 1 returned from tool NuGet.exe
I have also attempted to use a personal access token to no avail.
How do I get the publish step working?
The in-box NuGet Publish task has two options: "external" feeds and "internal" feeds. External feeds are intended for 3rd party services like NuGet.org, Artifactory, and expect a service connection with an API key.
Internal feeds are those hosted by Team Services. Instead of a service connection, you add the URL of the feed's NuGet endpoint. The build system relies on the Project Collection Build Service (for collection-scoped build definitions) or Project Build Service (for "this project"-scoped build defs) being a Reader or Contributor to the feed. Docs for all that are available here.
UPDATE: It is all fixed now so you can use the standard packaging steps in vNext and they work like a charm.
For the time being, I am substituting the NuGet Publisher step with a PowerShell build step.
This slots into the build after the "NuGet Packager" step and allows me to specify all of the credentials by setting up a package source before pusing the package.
$feedUrl = "https://example.pkgs.visualstudio.com/DefaultCollection/_packaging/Example/nuget/v3/index.json"
$packagePath = $ENV:BUILD_REPOSITORY_LOCALPATH + "\YourOrg.YourComponent." + $ENV:BUILD_BUILDNUMBER + ".nupkg"
Write-Host "Adding package Source"
$addSourceCommand = $ENV:BUILD_REPOSITORY_LOCALPATH + "\nuget sources add -name ""Example"" -source " + $feedUrl + " -username ""your.username"" -password ""yourpassword"""
Invoke-Expression -Command $addSourceCommand
Write-Host "Pushing package to NuGet"
$pushCommand = $ENV:BUILD_REPOSITORY_LOCALPATH + "\nuget push $packagePath -Source " + $feedUrl + " -ApiKey Example"
Invoke-Expression -Command $pushCommand
I landed here because I'm researching/configuring an internal deploy -- where I'm running my own NuGet Server (nuget.server, as opposed to visual studio online). The error was the same (or has similar text):
Object reference not set to an instance of an object
My solution, it turned out, was that the URL wasn't right.
The correct version is: http://server-name/NuGet/api/v2/package
For completeness, I had: http://server-name/NuGet/ which was wrong.

Install4J Install into different directory selected but ignored on install

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

Unable to install a VSTO excel 2003 AddIn

I developped a VSTO SE Excel 2003 add in.
When launching and debuging the add in from visual studio, it works well.
But when I try to deploy it from my own install it never works.
To sum up, here is my install process:
the files are copied at the right location
I register the addin:
HKEY_CURRENT_USER\Software\Microsoft\Office\Excel\Addins\
with the appropriate values (Default, CommandLineSage, Description, FriendlyName, LoadBehavior, Manifest).
I also add entries in
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ (with CLSID key including an UUID)
And HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}
with InprocServer32 (with the manifest name and path, the addinloader.dll fullpath), ProgID (with the assembly name (without extension)), Programmable and VersionIndependententProgID (with the assembly name too).
I set the fulltrust policy to the url of every assemblies using caspol -m -ag "xxx" -url "MyUrl\Assemblies.dll" FullTrust -name "name"
Do I miss something ?
In the deployment machine, check whether the following are available:
Currect version of VSTO Runtime
Office 2003 Primary Interop Assesmblies
regards,
yenkay...
A good way to debug VSTO installation/loading issues is to have VSTO show you all errors. To do that, create an environment variable called VSTO_SUPPRESSDISPLAYALERTS with the value 0, reinstall/repair your addin, then try running Excel again.
It looks like the problem is with your registry keys. Check out the following link:
http://msdn.microsoft.com/en-us/library/bb386106.aspx
Your Software\Classes and Software\Microsoft entries should be under the same key, either HKCU or HKLM. If you have one under HKCU and the other under HKLM, it messes up the addin.
So I think the registry entry HKEY_CURRENT_USER\Software\Microsoft\Office\Excel\Addins\ should be HKEY_LOCAL_MACHINE\Software\Microsoft\Office\Excel\Addins.
HTH...