Skip to content

Commit ed8c093

Browse files
junianVesaJuvonen
authored andcommitted
Fix code block formatting (SharePoint#2266)
1 parent 63f9d08 commit ed8c093

File tree

1 file changed

+18
-19
lines changed

1 file changed

+18
-19
lines changed

docs/sp-add-ins/update-add-in-web-components-in-sharepoint.md

Lines changed: 18 additions & 19 deletions
Original file line numberDiff line numberDiff line change
@@ -192,7 +192,7 @@ Because there is already such an element in the **ElementManifests** section, si
192192

193193
3. Add the following markup to the **asp:Content** element, and then replace _{RelativePathToNewPageFile}_ with the new path and file name. This script redirects the browser to the new page and includes the query parameters. It also keeps the old page out of the browser history.
194194

195-
```
195+
```html
196196
<script type="text/javascript">
197197
var queryString = window.___location.search.substring(1);
198198
window.___location.replace("{RelativePathToNewPageFile}" + "?" + queryString);
@@ -274,25 +274,24 @@ For the most part, this is exactly what should occur: you want every earlier ver
274274

275275
Each time that you upgrade the Feature, follow the same pattern. Add a new **VersionRange** for the latest update actions. Add an **EndVersion** element to the _previous_ **VersionRange** element and set it to the previous version number. In the continuing example, the file would resemble the following for the update from 3.0.0.0 to 4.0.0.0.
276276

277-
278277
```XML
279-
<Feature <!-- Some attributes omitted -->
280-
Version="4.0.0.0">
281-
<ElementManifests>
282-
<!-- Child elements omitted -->
283-
</ElementManifests>
284-
<UpgradeActions>
285-
<VersionRange EndVersion="2.0.0.0">
286-
<!-- Child elements for upgrade from 1.0.0.0 to 2.0.0.0 go here. -->
287-
</VersionRange>
288-
<VersionRange EndVersion="3.0.0.0">
289-
<!-- Child elements for upgrade from 2.0.0.0 to 3.0.0.0 go here. -->
290-
</VersionRange>
291-
<VersionRange>
292-
<!-- Child elements for upgrade from 3.0.0.0 to 4.0.0.0 go here. -->
293-
</VersionRange>
294-
</UpgradeActions>
295-
</Feature>
278+
<Feature <!-- Some attributes omitted -->
279+
Version="4.0.0.0">
280+
<ElementManifests>
281+
<!-- Child elements omitted -->
282+
</ElementManifests>
283+
<UpgradeActions>
284+
<VersionRange EndVersion="2.0.0.0">
285+
<!-- Child elements for upgrade from 1.0.0.0 to 2.0.0.0 go here. -->
286+
</VersionRange>
287+
<VersionRange EndVersion="3.0.0.0">
288+
<!-- Child elements for upgrade from 2.0.0.0 to 3.0.0.0 go here. -->
289+
</VersionRange>
290+
<VersionRange>
291+
<!-- Child elements for upgrade from 3.0.0.0 to 4.0.0.0 go here. -->
292+
</VersionRange>
293+
</UpgradeActions>
294+
</Feature>
296295
```
297296

298297
Notice that the most recent **VersionRange** element has no **BeginVersion** or **EndVersion** attributes. This ensures that the upgrade actions that go into this **VersionRange** element are applied to all previous versions of the Feature, which is what you want because all the latest changes are referenced in this **VersionRange**, and none of them have already occurred for any instance of the Feature.

0 commit comments

Comments
 (0)