c# pdf viewer free : Reorder pages in pdf file SDK control service wpf web page .net dnn Windows%20Powershell%20in%20Action%202nd%20Edition40-part1495

370
CHAPTER 10
M
ODULE
MANIFESTS
AND
METADATA
The final type of dependency is on the modules that are already loaded into the 
system. This is done through the 
RequiredModules
manifest element. This element 
probably doesn’t do what you’d expect. It doesn’t load dependencies—it just checks to 
see if certain modules are loaded. This seems a bit useless but, perhaps the version of 
the required module currently loaded is too low and a newer module can’t be loaded 
because there are other modules already using the loaded module. Whereas the other 
elements you’ve seen so far are either simple strings or strings that can be converted 
into a version number, this element can either take a module name string or a hash 
table containing two or three elements. These hash table elements allow you to pre-
cisely specify the module you’re dependent on as they include the module name, the 
version number, and the 
GUID
of the module that must be loaded (although the 
GUID
is optional).
This covers all the production elements in the manifest. Now that you know you 
have the right module (Identity) and that it will work in your environment (Depen-
dencies), let’s look at the manifest elements that control what happens when the mod-
ule is loaded. Load-time behavior is controlled by a set of manifest elements that 
contain entries that are used to construct the in-memory representation of the module.
10.4
C
ONSTRUCTION
MANIFEST
ELEMENTS
The construction metadata in this module are the fields that tell the engine what to 
load as part of this module. These fields are listed in table 10.2.
Table 10.2 The module manifest elements that contain data used in constructing the module
Manifest element
Type
Default 
value
Description
ModuleToProcess
string
''
Script module or binary module file associ-
ated with this manifest
RequiredAssemblies
[string[]]
@()
Assemblies that must be loaded prior to 
importing this module
ScriptsToProcess
[string[]]
@()
Script files (.ps1) that are run in the caller’s 
environment prior to importing this module
TypesToProcess
[string[]]
@()
Type files (.ps1xml) to be loaded when 
importing this module
FormatsToProcess
[string[]]
@()
Format files (.ps1xml) to be loaded when 
importing this module
NestedModules
[string[]]
@()
Modules to import as nested modules of the 
module specified in ModuleToProcess
FunctionsToExport
String
"*"
Functions to export from this module
CmdletsToExport
String
"*"
Cmdlets to export from this module
VariablesToExport
String
"*"
Variables to export from this module
AliasesToExport
String
"*"
Aliases to export from this module
Reorder pages in pdf file - re-order PDF pages in C#.net, ASP.NET, MVC, Ajax, WinForms, WPF
Support Customizing Page Order of PDF Document in C# Project
how to move pages in a pdf; how to move pages around in a pdf document
Reorder pages in pdf file - VB.NET PDF Page Move Library: re-order PDF pages in vb.net, ASP.NET, MVC, Ajax, WinForms, WPF
Sort PDF Document Pages Using VB.NET Demo Code
how to reorder pages in pdf preview; rearrange pages in pdf file
C
ONSTRUCTION
MANIFEST
ELEMENTS
371
There  are  two  subcategories  in  the  construction  elements:  “things  to  load”  and 
“things to export.” We’ll start with loading because you can’t export anything until 
something has been loaded. As mentioned previously, none of the fields are required. 
If they aren’t there, then PowerShell assumes the default value for each field, as shown 
in the table.
10.4.1
The loader manifest elements
The next few sections cover each of these manifest elements in the order that you’re 
most likely to use them in when creating a manifest. This isn’t the order that they’re 
processed in when the module is loaded. We’ll cover the load order as a separate topic 
(in section 10.4.2).
ModuleToProcess manifest element
The first loader element we’ll discuss is 
ModuleToProcess
. It’s the most commonly 
used manifest element and identifies the main, or root, active module to load. 
NOTE
So why isn’t it  called 
RootModule
? Because the PowerShell 
team named (and renamed and renamed again) this field throughout 
the development process, but it wasn’t until everything was done and 
we started to explain it to other people that the concept of a “root mod-
ule” started spontaneously popping up conversations. Unfortunately, 
by then we were too far into the release process to be able to change it. 
Thus, 
RootModule
became victim of the tyranny of the clock.
By active, I mean that the file defines executable elements, instead of just providing 
metadata definitions. The type of the module file specified in this member will deter-
mine the final module type. If no file is specified as the 
ModuleToProcess
, then the 
type shown in the module information object will be 
Manifest
. If it’s a script or 
binary module, it will be the respective module type. Other types will raise errors. 
The various combinations are shown in table 10.3.
If a script or binary module is specified in the 
ModuleToProcess
element, the type 
of the loaded module will be the same as the type of the module specified in the
Table 10.3 Module types as determined by the ModuleToProcess member
Contents of ModuleToProcess
Final module type
empty
Manifest
Script module (.psm1)
Script
Binary module (.dll, .exe)
Binary
Module manifest (.psd1)
Error—not permitted
Script file
Error—not permitted
C# TIFF: How to Reorder, Rearrange & Sort TIFF Pages Using C# Code
C# TIFF - Sort TIFF File Pages Order in C#.NET. Reorder, Rearrange and Sort TIFF Document Pages in C#.NET Application. C# TIFF Page Sorting Overview.
reordering pages in pdf; move pages within pdf
C# PDF Page Rotate Library: rotate PDF page permanently in C#.net
C# .NET, add new PDF page, delete certain PDF page, reorder existing PDF pages and split may choose to only rotate a single page of PDF file or all
move pages in pdf online; pdf reverse page order
372
CHAPTER 10
M
ODULE
MANIFESTS
AND
METADATA
ModuleToProcess
element even though you’re loading through a manifest. In other 
words, if the root module was binary, the 
Type
property on the module information 
object shows 
Binary
 If  the root module  was  script  module,  the 
Type
property 
returns 
Script
. What it can’t be, however, is another manifest module. It must be 
either a script or binary module (or be left empty). The reason for this constraint is 
that the job of a manifest is to add metadata to a script or binary module. If the 
main module is another manifest, you’d have to deal with colliding metadata. For 
example, one manifest may declare that the module is version 1.0.0.0 but the second 
module says it’s version 1.2.0.0. There’s no way to reconcile this type of collision so 
it’s simply not allowed. As a result, PowerShell just won’t look for a .psd1 file when 
searching for the module to process. As mentioned at the beginning of this subsec-
tion, it’s expected that production modules will use 
ModuleToProcess
to identify a 
single main module.
NestedModules manifest element
We’ll review 
NestedModules
next. 
NestedModules
are loaded before the 
Module-
ToProcess
is loaded. Although the net effect is equivalent to having the main mod-
ule call 
Import-Module
, there are two advantages to this approach. First, it’s easy to 
see what the module is going to load before loading the module. Second, if there’s a 
problem with loading the nested modules, the main module won’t have been loaded 
and won’t have to deal with the load failures. 
RequiredAssemblies manifest element
The 
RequiredAssemblies
field sounds like it should have the same behavior as 
RequiredModules
from the previous section. It doesn’t. This field loads the assem-
blies listed in the element if they aren’t already loaded. Figure 10.4 shows the set of 
steps taken when trying to find the module to load.
If one of the steps results in a successful load, PowerShell will proceed to the next 
step in loading a module. If it fails, the entire module loading process is considered a 
failure.
ScriptsToProcess manifest element
Now let’s talk about 
ScriptsToProcess
and scripts in general. Something we didn’t 
discuss earlier is that 
NestedModules
can also refer to script files. These script files 
are run in the root module’s context—essentially equivalent to dot sourcing them 
into the root module script. The scripts listed in 
ScriptToProcess
do something 
quite different. These scripts are run in the caller’s environment, not the module 
environment, and are run before any of the modules are loaded. This allows for cus-
tom setup and environment validation logic. We talked about how version checks 
work—the first module with a version number equal to or greater than the requested
VB.NET PowerPoint: Sort and Reorder PowerPoint Slides by Using VB.
Sort and Reorder PowerPoint Slides Range with VB amount of robust PPT slides/pages editing methods powerful & profession imaging controls, PDF document, image
pdf move pages; reorder pdf pages
VB.NET TIFF: Modify TIFF File by Adding, Deleting & Sort TIFF
Users can use it to reorder TIFF pages in ''' &ltsummary> ''' Sort TIFF document pages in designed powerful & profession imaging controls, PDF document, image
change pdf page order; reverse pdf page order online
C
ONSTRUCTION
MANIFEST
ELEMENTS
373
version number will be loaded, assuming that things are backward compatible. In 
fact, this might not be true but there’s no explicit support for this level of dependency 
checking currently. If you’re in a situation where you have to do this, you can use a 
script referenced in 
ScriptsToProcess
.
TypesToProcess and FormatsToProcess manifest elements
The last  of  the “loaded”  manifest  elements  are 
TypesToProcess
and 
Formats-
ToProcess
. These are files with a .ps1xml extension that contain formatting instruc-
tions and additional type metadata. (We’ll delve more into the content of these files 
in chapter 16.)
Load using
assembly name
Try to load assembly using assembly qualified
name using Assembly.Load() method
Load using a path
name
Load using a
partial name
Try to load assembly using a path with 
Assembly.LoadFrom() method
Try to load assembly using partial assembly name
with Assembly.LoadWithPartialName() method
Success?
Success?
No
Yes
Load failed;
generate error and 
halt processing
No
No
Load succeeded;
continue 
processing
Figure 10.4 The steps taken when trying to load an assembly from the 
RequiredAssemblies
module manifest field
C# PDF: C# Code to Process PDF Document Page Using C#.NET PDF
delete or remove certain page from PDF document file. C# PDF Page Processing: Sort PDF Pages - online C#.NET tutorial page for how to reorder, sort, reorganize
how to rearrange pdf pages in preview; how to rearrange pages in pdf using reader
Read PDF in Web Image Viewer| Online Tutorials
for image viewing to read, edit, create or write PDF documents from file or stream in Extract images from PDF documents; Add, reorder pages in PDF
move pdf pages online; how to change page order in pdf acrobat
374
CHAPTER 10
M
ODULE
MANIFESTS
AND
METADATA
10.4.2
Module component load order
Module  components  are  loaded  into  the  PowerShell  environment  using  a  fixed 
sequence of steps called the module load order. This load order is shown in figure 10.5.
The order that these steps are taken in can be of significance when you’re trying to 
construct a module with a complex structure. In particular, there’s an issue load order 
that causes problems when using binary modules with types and format files.
Because types and format files are loaded before 
ModuleToProcess
is, if the types 
and format files contain references to any of the .
NET
types in the binary module, an 
error saying that the referenced types can’t be found because the module’s 
DLL
hasn’t 
been loaded yet will occur. To work around this, you need to make sure the 
DLL
for
Validate module manifest
Make sure module manifest is
syntactically correct and contains only 
valid members. Also verify that it
contains a version number.
Check RequiredModules
Process RequiredAssemblies
Load types and format files
Load nested modules
Load module to process
Add to module table
Process exports
Raise error if any required modules
aren’t currently loaded. Missing modules
won’t be loaded.
Check for required assemblies, and load
any that are missing.
Process all type .ps1xml files; then load
all format .ps1xml files.
Load all nested modules in the order
they appear in manifest element.
If no errors have occurred up to this
point, module has loaded successfully
and is added to module table.
Import all members exported from main
module context, subject to filters
specified for Import-Module cmdlet. 
Finally, load main module if one has
been specified.
Figure 10.5 The ordering of the steps when processing a module manifest. If 
an error occurs at any point prior to the next-to-last step, module processing 
will stop and an error will be thrown.
VB.NET TIFF: VB.NET Sample Code to Process & Manage TIFF Page
certain TIFF page, and sort & reorder TIFF pages in Process TIFF Pages Independently in VB.NET Code. powerful & profession imaging controls, PDF document, image
reorder pages pdf file; move pdf pages in preview
C# Word: How to Create Word Document Viewer in C#.NET Imaging
in C#.NET; Offer mature Word file page manipulation functions (add, delete & reorder pages) in document viewer; Rich options to add
rearrange pdf pages online; how to rearrange pdf pages online
C
ONTENT
MANIFEST
ELEMENTS
375
the binary module is loaded first. You do so by adding the 
DLL
to the list of 
Required-
Assemblies
. Because 
RequiredAssemblies
is processed before the types and format 
file entries, there won’t be a problem resolving the types. Then, when it’s time to load 
the binary module, the 
DLL
will already be loaded and will just need to be scanned to 
find the cmdlets and providers. This resolves the problem with effectively no perfor-
mance impact and only a small increase of complexity for the module owner.
At this point, we’ve covered all the major module manifest topics. There are only 
a couple of things left to look at and then we’ll be done.
10.5
C
ONTENT
MANIFEST
ELEMENTS
The content manifest  elements are the component files that make  up a module. 
There are two lists provided: a list of all loadable module files and a separate list for 
any other files (data files, icons, audio clips, and so on) that are part of the module. 
These elements are shown in table 10.4.
Note that these “packing lists” are not normative. In other words, they aren’t processed 
or enforced by PowerShell and filing them is entirely optional. As a best practice, 
though, it’s recommended that they contain accurate data because external tools may 
be created to do the actual validation.
This last manifest element—
PrivateData
—provides a way for module writers to 
include custom data in manifests and make it available to modules when loaded. This 
element can contain any type of object permitted by the restricted language subset of 
PowerShell: strings, numbers, arrays, or hash tables. The system makes the data avail-
able to both script and binary modules, including to providers defined in binary 
modules. We’ll look at how modules can access the data specified by this element in 
section 10.7.3.
At long last, we’ve covered all the manifest elements. We have one last thing to 
look at before we’re done with manifest content. Back in section 10.2, we said that, 
although manifests are written in PowerShell, they use a restricted subset of the lan-
guage. The restricted language is used to reduce the potential security risk associated 
with loading a script. This allows you to load a manifest file to access the metadata 
without being concerned that you’ll execute malicious code. This also means that you
Table 10.4 Module manifest elements used to list the module’s contents
Manifest element
Type
Default value
Description
ModuleList
[string[]]
@()
Non-normative list of all modules packaged 
with this module
FileList
[string[]]
@()
Non-normative list of all files packaged 
with this module
PrivateData
[object]
''
Private data to pass to the module 
specified in ModuleToProcess
376
CHAPTER 10
M
ODULE
MANIFESTS
AND
METADATA
need to know how to write these scripts properly. In the next section, you’ll learn 
what you can do in a manifest file.
10.6
L
ANGUAGE
RESTRICTIONS
IN
A
MANIFEST
Because the manifest is a PowerShell data file, its contents are restricted to a small 
subset of PowerShell language features. This subset includes the basic PowerShell data 
types (numbers, strings, hash tables, and so on), the 
if
statement, and the arithmetic 
and comparison operators. Things like assignment statements, function definitions, 
and loop statements aren’t allowed. (See appendix 
D
for full details on the language 
limitations.)
With only these elements, you’d be limited to using static values for element defi-
nitions. This means you wouldn’t be able to accommodate for variations in system 
configuration—things like paths to system directories, software installation directo-
ries, and drive letters. To allow you to handle these situations, manifests are permit-
ted to read (but not write) the 
$ENV:
environment provider and can use the 
Join-
Path
cmdlet to construct paths at runtime. This allows manifest elements to be writ-
ten in such a way that system differences can be handled.
Let’s look at an example illustrating how these features can be used. In this exam-
ple, imagine you have an application that uses PowerShell for management. This 
application installs its PowerShell modules in a directory in the module path, and 
then puts the rest of the application files in 
Program Files
. Because the modules 
need access to some of the resources in the application directory, the application 
installer will set an environment variable, 
$ENV:MYAPPDIR,
at install time that can be 
used by the manifest to find the necessary resources. A module entry using this envi-
ronment variable would look like this:
RequiredAssemblies = (Join-Path $ENV:MYAPPDIR requiredAssembly.dll)
In the fragment, the 
Join-Path
cmdlet is used to generate the absolute path to the 
required assembly using 
$ENV:MYAPPDIR
. Now, to complicate things we’ll say that 
this library is processor dependent, and you’ll need to load a different 
DLL
based on 
the  setting  of  the  system  variable 
$ENV:PROCESSOR_ARCHITECTURE
 This  entry 
would look like 
RequiredAssemblies = if ($ENV:PROCESSOR_ARCHITECTURE -eq "X86") { 
Join-Path $ENV:MYAPPDIR requiredAssembly.dll
} else {
Join-Path $ENV:MYAPPDIR64 requiredAssembly.dll
}
This second example uses the 
if
statement to select a different branch based on the 
processor architecture and then generates the system-specific path using 
Join-Path
These techniques allow modules to be flexible when dealing with system variations.
One thing missing from the module manifest story is the ability for scripts to read 
the manifest files without loading the module. This is unfortunate because it limits
L
ANGUAGE
RESTRICTIONS
IN
A
MANIFEST
377
your ability to write scripts to explore the modules you have. The 
Test-Module-
Manifest
cmdlet does process the manifest but it doesn’t return all the data in the 
manifest file. Because the language in the manifests is a subset of regular PowerShell, 
it’s possible to load the module file contents into a string and then use 
Invoke-
Expression
to evaluate it. This will give you the data you want, but it means that 
the module is no longer running in restricted mode. As a workaround, you can use a 
hybrid approach. First, you’ll validate  the manifest with 
Test-ModuleManifest
This will verify that the manifest only contains elements that are permitted in the 
restricted language. Then you’ll read and evaluate the module file to get the data. The 
following listing shows a function that can be used to do this.
function Read-ModuleManifest ($manifestPath) 
{
trap { break }
$fullpath = Resolve-Path $manifestPath -ErrorAction Stop 
if (Test-ModuleManifest $fullPath) 
{
$PSScriptRoot = Split-Path -Parent $fullPath
$content = (Get-Content $fullPath) -Join "`n"
Invoke-Expression $content           
}
Let’s use this function to load the 
BitsTransfer
module manifest:
PS {1) > cd $pshome\modules\BitsTransfer 
PS {2) > Read-ModuleManifest .\BitsTransfer.psd1
Name                           Value 
----                           -----
ModuleVersion                  1.0.0.0 
CLRVersion                     2.0 
FormatsToProcess               BitsTransfer.Format.ps1xml 
PowerShellVersion              2.0 
GUID                           {8FA5064B-8479-4c5c-86EA-... 
NestedModules                  Microsoft.BackgroundIntel... 
Copyright                      c Microsoft Corporation. ... 
CompanyName                    Microsoft Corporation 
Author                         Microsoft Corporation 
RequiredAssemblies             C:\Windows\System32\Windo...
The output of the function is the hash table defined in the manifest file.
And we’re done with manifests! Like bookkeeping and inventory management, 
manifests are complicated and a bit boring but absolutely necessary when doing pro-
duction scripting. In the next section, we’ll explore features that are less tedious but 
(hopefully) more exciting.
Listing 10.1    The Read-ModuleManifest function
Load manifest text
Evaluate with 
Invoke-Expression
378
CHAPTER 10
M
ODULE
MANIFESTS
AND
METADATA
10.7
A
DVANCED
MODULE
OPERATIONS
In this section, you’ll learn sophisticated things you can do with modules. These fea-
tures are not intended for typical day-to-day use, but they allow for some sophisti-
cated scripting. As always, if you aren’t just scripting for yourself, have pity on the 
person who will have to maintain your code and avoid “stunt scripting.” 
10.7.1
The PSModuleInfo object
PowerShell modules, like everything in PowerShell, are objects you can work with 
directly.  The  type  of  the  object  used  to  reference  modules  is 
System.Manage-
ment.Automation.PSModuleInfo
.
You’ve  been  looking  at  these  objects  all  along—this  is  what 
Get-Module 
returns—but you’ve only been using them to get basic information about a module. 
In practice, there are a lot of other things that can be done once you have a 
PS-
ModuleObject
. In this section, we’ll look at what can be done (and try to explain 
why you’d do these things).
Invocation in the module context
In our discussion about module scopes, we introduced the concept of a module-level 
scope, which is used to isolate the private variables and functions. When you execute 
code where function and variable lookup is done in a module scope, we call this “exe-
cuting in the module context.” This is what happens anytime you execute a function 
that has been exported from a module. But you can also cause arbitrary code to be 
executed in the module context even though it wasn’t defined in that context. In 
effect, you’re pushing code into the module context. This is done with a 
PSModule-
Info
object using the call operator 
&
.
NOTE
Yes, this ability to inject code into a module context violates all 
the principles of isolation and information hiding. And from a lan-
guage perspective, this is a bit terrifying, but people do it all the time 
when debugging. One of the nice things about dynamic languages is 
that you’re effectively running the debugger attached all the time. 
To try this out, you’ll need a module object to play with. Let’s load the 
counter 
module we looked at in section 9.4.1 again. First, let’s quickly review the contents of 
the module—you’ll use the 
Select-Object
cmdlet to limit what gets output to the 
first eight lines, as that’s all you’re concerned with here:
PS (1) > Get-Content counter.psm1 | select -First 8 
$script:count = 0 
$script:increment = 1
function Get-Count 
{
return $script:count += $increment 
}
A
DVANCED
MODULE
OPERATIONS
379
This module has private state in the form of the two variables—
$count
and 
$incre-
ment
—and one public function, 
Get-Count
. Now import it
PS (2) > Import-Module .\counter.psm1
and use 
Get-Module
to get the module reference:
PS (3) > $m = Get-Module counter
You could have done this in one step with the 
-PassThru
parameter, as you saw ear-
lier, but we’re using two steps here to illustrate that these techniques can be done with 
any in-memory module. Now run the 
Get-Count
function and it returns 1, as it 
should right after the module is first loaded:
PS (4) > Get-Count 
1
Now set a global variable, 
$count
, using the 
Set-Variable
command (again, we’re 
using  the  command  instead  of  assignment  to  set  the  variable  for  illustration 
purposes):
PS (5) > Set-Variable count 33
When you run 
Get-Count
again, it returns 2 because the 
$count
variable it uses 
exists in the module context:
PS (6) > Get-Count 
2
So far nothing much to see. Now let’s do something a bit fancier. Let’s see what the 
current value of 
$count
in the module context is. You can do this by invoking 
Get-
Variable
in the module context with the call operator:
PS (7) > & $m Get-Variable count
Name                           Value 
----                           -----
count                          2
You see the value is 2. Great—now you can inspect the private inner state of a module 
to  see  what’s  going  on.  Next,  let’s  alter  that  state.  You’ll  execute  the  same 
Set-
Variable
command as before, but inside the module this time:
PS (8) > & $m Set-Variable count 33
Call 
Get-Count
to verify that you have made a change:
PS (9) > Get-Count 
34
The call to 
Get-Count
returned 34, so you’ve successfully changed the value of the 
variable it uses in its operation.
Documents you may be interested
Documents you may be interested