This week, we ran to the customer to deploy the newly developed Silverlight application. I was dumpfounded when I went to the client for installation. Last week, I began to rebuild the overall network environment to adapt to security and confidentiality checks.
1. Installation of the. NET 3.5 framework complete installation package fails because a Language Pack needs to be downloaded from the Microsoft website when the. netframework 3.5 complete installation package is used normally. The current network environment does not allow Internet access, so installation fails.
Then, the. NET 3.5 framework is successfully installed in the offline installation mode. The method is as follows:
1.1 run the command line dotnetfx35.exe/X to decompress it to a directory.
1.2 go to the extract directory and enter WCU \ dotnetframework
1.3 run dotnetfx35setup.exe/lang: enu from the command line
2. Another problem occurs when installing the Silverlight plug-in: Because domain users do not have the Administrator permission, and Silverlight installation requires the Administrator identity, I am so dumb that I don't know how to handle it. After collecting a large amount of information, we found that Silverlight must be installed as an administrator. The method that comes to mind later is domain distribution, while the Silverlight installation package is a compressed package exe program, which cannot be identified during domain distribution.
The Silverlight. MSI and Silverlight. MSP (Windows Install patches) are found to be decompressed. In fact, the normal installation process is to install Silverlight. MSI first, and then install Silverlight. MSP.
The new idea is to create an MSI installation package program, integrate Silverlight. MSI and Silverlight. MSP, and run these two files separately during the installation process. Installation package created,
However, a new problem occurred while running Silverlight. MSP: the program to be upgraded was not found. Once again, I was dumpfounded to collect MSP data online. There is no description of the MSP file and I don't know how to solve it.
After learning about the Silverlight installation process, we found that the Silverlight Installation Package released by Microsoft has the Silent Installation function.
Silent Installation
Silverlight.exe/qu-silent uninstall
The new idea is to package silverlight.exe into MSI, and then run this EXE in the MSI installation package for Silent Installation. However, Silverlight cannot be installed during the running of the MSI installation package. Depressed again.
It is best to decide to create the Silverlight installation package program by yourself. However, I do not know which registries are written during the Silverlight installation process.
2.1 export the entire registry before installing Silverlight.
2.2 After Silverlight is installed, the entire registry is exported and compared with the file difference comparison tool to find the Registry location.
After making these differential registries in the new MSI installation package, we found that the original Microsoft Silverlight installation package is actually registering an npctrl. dll file.
However, there is another problem: regsvr32 npctrl. dll fails to be registered during domain distribution, which is quite depressing. no perfect solution has been found so far.
The MSI installation package created for the customer is to directly write the registry. Although Silverlight can be installed normally, it still feels uncomfortable and is still looking for a solution.
Which of the following heroes knows? Hahaha.
The above are some of my experiences in deploying Silverlight... Make notes
I don't know if Silverlight installation will be as convenient as flash in the future... Hey hey...
There are still two issues to be resolved:
1. Why does regsvr32 npctrl. dll fail during domain distribution installation?
2. Why does Silverlight. MSI and Silverlight. MSP fail to find the successfully installed Silverlight program when they are integrated into MSI ..
Updated on 2010-03-26:
Then we found a new idea: In domain distribution, we used the Windows startup script to set and run silverlight.exe/Q. The installation is successful in the test environment.