There is an issue with PostSharp 1.5 and 2.0 that won't let you install it on the Windows 7 machine with the error message ".NET Framework 2.0 is not present on this computer".
To work around the issue you have to run the installer while being logged in with Administrator account. Not Admin group and not "run as Administrator", you have to be logged in with the Administrator account. Hope that helps, if someone has the same issue.
You can also open a command prompt under Administrator priviledge, then invoke the .msi installer
The possible reason was incorrect registry value -
see http://www.sharpcrafters.com/forum/Topic8623-18-1.aspx#m8766
the registry value "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET
Framework Setup\NDP\v3.5\SP" is set to 0 on your computer but was
expected to be 1.
you can set this registry value to 1 for the time of installation,
then set it back to 0
it is a known , not PostSharp specific issue: https://superuser.com/questions/106647/net-framework-3-5-sp1-on-wind...
Related
I'm trying to install mongo DB on my local machine with the installer from the official website. But I'm continuously getting this message, can someone help?
I've tried the solution provided here but didn't help.
I suggest doing the following:
Hit Win+R to open up you run.exe then inside of it enter services.msc to open up services. Try locating the service under the name of MongoDB Server and set the Startup Type manually to Automatic - [In addition to that, you could set the username and password manually. If you get a message saying the user was granted login as a service right, try hitting retry on the MSI dialog and see if it starts].
Important:
Don't forget to save and close everything (services.msc) before continuing.
Also very important, you should (must) check your .NET framework version and update it to version 4.5 and above. You could download a software like eg Driver Booster to update all of your drivers and additional components that are outdated.
I ran into the same issue. My problem was the installation location. I was trying to install under C:\MongoDB. I resolved it by installing in the default MongoDb location which is C:\Program Files\MongoDB.
For me this is usually an issue with the configuration file %ProgramFiles%\MongoDB\Server\x.x\bin\mongod.cfg
At some time there was an invalid option "snmp" enabled (only valid in enterprise version).
Nowadays, although the installer asks for directories for data and logs it doesn't ALWAYS seem to use these, but defaults to %MONGO_DATA_PATH% or %MONGO_LOG_PATH%, respectively. I don't know where these should be defined, but the server fails at accessing c:\data\db (which doesn't exist). So you have to correct the paths.
I also faced this kind of error. But I just change the Network service to Local system in Log On As tab.
Follow my step-by-step below to resolve it:
Press Win+R, type: services.msc, then looking for MongoDB Server (MongoDB)
Double click on MongoDB Server (MongoDB).
Then it will open properties tab. On that tab click on Log On
After that check two items i.e. Local System account and Allow service to interact with desktop
After that press Apply and OK button. That's it, cheers!!
Open command prompt and copy the following command:-
"C:\Program Files\MongoDB\Server\4.2\bin\mongo.exe"
NOTE: This Tricks is work on my Windows 8.1 PC.
Comment out string with mp: in configuration file: %ProgramFiles%\MongoDB\Server\x.x\bin\mongod.cfg
Like this:
...
#snmp:
#mp:
Click Windows+r, type lusemgr.msc , Go to Groups and double click Administrators, Click Add, Click Advanced and click Find Now. Double click in Network Service (in bottom list) and click OK.
It worked for me.
Installing in the other locations other than the windows directory caused me this error. Reinstalling the setup with the recommended method of "complete" fixed it.
The problem occurs if you have Windows version previous to Windows 10.
Install the following update before installing MongoDB. Click on the link below.
https://support.microsoft.com/en-us/help/2999226/update-for-universal-c-runtime-in-windows
It worked for me.
The problem occurs if you have Windows version previous to Windows 7. Install the following update by going to below link you have to download
Windows6.1-KB2999226-x64.msu
#You have to download and install then go to servies.msu and start MongoDB server by Start also go into log on and set to #local machine
https://support.microsoft.com/en-us/help/2999226/update-for-universal-c-runtime-in-windows
I have encountered an error when trying to launch Powershell ISE. The launch starts with 'Loading' displayed in the splash panel, then a dialog box comes up with "An unexpected error has occurred, and Windows PowerShell ISE must close"
I have Googled this error and come up with nothing specific, but I have followed a few steps that have been suggested for fixing other issues.
Platform: Windows 8.1 Pro
Powershell ISE product version: 10.0.14409.1005
(Cannot open shell so cannot run cmdlet to get exect version details)
Things I have tried
1 The plain Powershell shell **does** launch.
2 Tried launching ISE with -NoProfile & -MTA switches no luck
3 Rename powershel_ise.exe.config so it cannot be read in both System32 & WOW64 folders
4 Upgrade .NET Framework to 4.5.1
5 Upgrade Management Framework to 5.1
6 Other machines within our environment with same image and patch level have **not** encountered this problem
7 Cannot find an associated error in the Event viewer logs
I really don't want to blow the machine away and start again so any suggestions or fix would be appreciated !
Angus
I had the same issue, I was able to fix it with recreating my user profile.
You can log as different user and try to run powershell_ise in that profile, if it runs, so more likely you can fix it. Just have somebody with admin rights delete your profile, and then just log back. Or if you have admin rights go create another account with admin, go to system properties / user profiles and remove your current profile ( just save files you need to keep)
"I renamed the C:\Users<name>\Documents\WindowsPowerShell directory and re-ran ISE and it didn't crash. Something up with that profile directory for me... –
Duncan Smart
Feb 10 '21 at 11:07"
Solved my similar issue! :D
Go to Documents C:\Users<loggedinProfileName>\Documents\WindowsPowerShell and re name from WindowsPowerShell to Old_WindowsPowerShell it will work if its crashes because for user profile.
My current environment is Windows 7 Enterprise Edition(SP1) with PowerShell V5
PSVersion = 5.0.10586.117
For somehow when I try to run the following statement (it worked well before)
new-object System.Net.WebClient
I started to get the following error
I checked
$ExecutionContext.SessionState.LanguageMode
and the result is: ConstrainedLanguage
I am now at a loss on how to change this LanguageMode to "FullLanguage" as mentioned in this URL
I googled around and do not see anything related to my environment, the closest link I see is here in MS technet forum. But in my case, I do not think it is AppLocker enabled (or do I have to ask my network admin to check the group policy?) and I do not see any SRP (Software Restriction Policy) on my local computer either.
Could someone please tell me how to fix this issue or how to check various aspects that lead to this LanguageMode change? or is there a way that I can edit the LangugageMode value?
Thanks in advance for your help.
Ok, after numerous attempts, I finally figured out why. I updated my WMF 5.0 production preview to the WMF 5.0 Production RTM about 10 days ago, but since then, I have not run any scripts including
new-object System.Net.WebClient
and as such, I never encountered the error mentioned.
After I uninstalled this WMF 5.0 Prod RTM version, I am now in PS Version 4.
PSVersion = 4.0
and when I run
$ExecutionContext.SessionState.LanguageMode
I get "FullLanguage" value as shown below
So I think it is kind of a bug for WMF 5.0 to Windows 7.0, and MS should fix it.
I checked my computer with Win 10 OS and WMF 5.0 RTM, the LanguageMode is still "FullLanguage".
[Edit]: 2016.Nov.25
I think I need to update this answer by saying that since the error occurred and I downgraded to V4, it solved the problem, but probably another two weeks later, I reinstalled WMF 5.0 (I believe the downloaded file is different from my initial downloaded file as the download link are different), now this solves the problem as well, i.e. in PS V5.0, the error does not appear again.Here is my current environment
To change the languagemode you can just use the variable:
$ExecutionContext.SessionState.LanguageMode = "FullLanguage"
I've been writing up a script that runs some server functions using a web-browser interface. I coded up the script on Windows 7 with Internet explorer 8 and it works fine.
As soon as I move it to the production server running Windows 2008 with Internet Explorer 9, it breaks. Finally traced it the point of failure, but I'm a bit stumped how to fix it.
Here's the code that will cause an issue:
$ie = new-object -com "InternetExplorer.Application"
$ie.navigate("http://www.google.com")
$ie.visible = $True
$doc = $ie.document
$Object1 = $doc.getElementByID("pocs")
This pops up an IE windows, and it should be able to search elements by ID. Trouble is, now I get the error
"Cannot find an overload for "getElementById" and the argument count:
"1"."
I can find very very little on this error. The actual issue is actually the variable $doc. If I do a "$doc | get-member" on IE 9 I get:
TypeName: System.__ComObject#{c59c6b12-f6c1-11cf-8835-00a0c911e8b2}
But under IE 8 I get:
TypeName: mshtml.HTMLDocumentClass
So, basically, IE 9 / Windows 2008 is failing to load the web document contents when I call $ie.document. I've tried setting IE9 to compatibility mode, but no luck there.
The $ie.document | get-member does actually show the method of : "getElementById Method Variant getElementById () " so it's in there, but there's no document for it to parse.
Any ideas would be greatly appreciated.
I am equally astonished this has not been fixed yet given the longevity of the issue on various technical forums. However I think I have found the solution, though it would be up to the Microsoft IE team to address at some point.
Like all the threads referenced that have looked into this I have suffered the same issue with the getElementById method, which with no other changes to a couple of test machines (one Windows 2008R2 Enterprise 64bit and one Windows 7 32bit), I can get the same script to work.
Workarounds that worked as temp solution that I didn't like:
Using the dev console in IE11, switch the Document Mode to 8 (9,10,11,Edge (default) don't work) - my automation script works instantly. No changes to IE trusted sites, zone security, protected mode, PowerShell session priveleges). So clearly just a component issue of the IE11 installation of some sort
Installing Office 2013, without ever running or licensing it, the same script works instantly without changing the Document Mode of IE11. Clearly Office does install/register something that fixes the problem (as Rhys Edwards says)
So I set about narrowing down what Office does to enable the COM object required for IE automation by:
Preparing a new Virtual Windows 2008R2 Server , no updates. Ran test script under IE8 - no issues.
Upgraded to IE11. Ran test script - failed as usual.
Took a VM snapshot
Used Regshot to do record the registry and file system
Ran the Office 2013 Pro_SP1 installation, no changes to default options
When Office install completes, did not run office once (at all ever)
Ran test script again - everything works, the IE automation with getElementById calls all back in operation
Took a 2nd VM snapshot
Ran 2nd scan with regshot and analysed the differences
Dumped the properties of my $ie object and also noticed there is far more there than before running Office install. References mshtml.dll and HTMLDocument classes throughout - looks as it should
I can see from the RegShot difference file that MSHTML.dll is ADDED and registered in the GAC (version 7.0.3300.0) by the office installation
What I did next may not be completely approved but:
I located the microsoft.mshtml.dll in the "c:\program files(x86)\Microsoft.net\primary interop assemblies" folder and saved it out of the VM to my local machine desktop
reverted to the pre-office 2013 snapshot
copied the microsoft.mshtml.dll into the VM and installed to the GAC (remember this is a 2008R2 server still on .net 2, I didn't update .net prior to or after IE11 install, only office). I installed to the GAC simply by dragging the file into the c:\windows\assembly view in explorer. In later versions of .Net you need to use gacutil /l
Tested the same script and BOOM, it all works fine. No need to change any IE settings or elevate script privileges or install Office
So to sum up. If you install IE11, to get PowerShell to automate the Document Model, I had to (re-)register the mshtml.dll in the GAC. Why the IE11 installation doesn't ensure this happens is beyond me but I think that the IE team need to look into this.
I also think for those where it 'just works' in IE10/11, you must have a product on the machine that has already registered the mshtml.dll in the GAC (perhaps Office, perhaps Visual Studio or some other MS app). Hence why you are not seeing the same problem that definitely exists.
Hope this helps someone - it was driving me crazy!
Andrew
As detailed in the comments on the question, there seems to be three solutions to this problem.
Upgrade to PowerShell 3.0: Version 2.0 is only compatible with up to IE8 when it comes to web-scraping and using IE as an object. However, version 3.0 will work with IE9. You can get it here.
Turn off protected mode in IE: Turning of protected mode for the Internet zone under the Security tab in settings seemed to do the trick for me. There are security implications to this that should be carefully considered.
Run the script in admin mode: Simply run the script in an elevated PowerShell prompt.
The last two solutions come from a different SO answer.
I had similar kind of issue and it got resolved by following below steps:
Check for the Microsoft.mshtml.dll on your machine. It should be available at location C:\Program Files (x86)\Microsoft.NET\Primary Interop Assemblies. If you don't find it at this location, It might be the case that you don't have this dll and this is the reason you are getting this issue.
Find the dll, and try to load the assembly at run time. You can place the dll at any location on you machine and do it.
Below is the link to a method to load assembly at run time.
https://onedrive.live.com/?cid=21ad54fd70600673&id=21AD54FD70600673%211922
Since years we use installshield to deliver our software. Since the last Version of our software the following happens:
After installing the program for "all users", when a restricted user logs in, he sees our applications Icon on the desktop. When double clicking it the first time a dialog appears "Configuring ". In recent versions after a while the dialog disappeared and our program stared. Now the process is aborted with a message: "The function is hosted on a unavailable network resource". Our program does not start. But when we create a shortcut to the .exe file by hand everything's fine.
We did not make any modifications to the installer project recently (besides changing the Version number). We also denied to install updates.
Questions:
What can the problem be?
How can i debug a installer?
Not so sure about Installshield (I use Wise) but you should check the following:
Set the MSI Property "ALLUSERS" to 1 in the "Property" table of the MSI database. See Windows Installer SDK documentation for more details. This ensures that all users get a shortcut for launching the application.
Call your installer with
MSIEXEC.EXE /v MyInstall.MSI
from the command line (this sets the logging to verbose) - might help!
Liam