Related
If I attempt to launch my .net core app I get this message. I realize there are many posts out there claiming to fix this but I have tried every method they suggest and none are working.
If I go into the project properties under debug and change the port, then it will connect 1 time. Then if I attempt to connect again, it will give me the same error again. I can then switch the port back to the original and it will load one time, then it will fail any time beyond that, until I switch it again. Anyone have any ideas or fixes they used?
Thanks!
I had this problem. There is a hidden folder in directory of project that name is '.vs'. Close the Visual Studio and delete this folder. The problem will be solved.
I installed core 2.0 and updated VS 2017 to 15.4.3 today, had the same error.
I ended up changing the application to run on a different port, it worked for me.
I have tried to delete the vs folder but did not work.
Hope it helps.
I know there is already an accepted answer to this question, but none of the solutions worked for me and my solution may help someone. I am using VS2017 with an ASP.NET Core 2.0 Razor Pages project.
The error just started appearing for no obvious reason, and I tried the solutions posted here.
I ran the web app from the command line using the dotnet run command to see if that would bring up any meaningful errors, and there was a warning about the URL not being correctly bound. I looked in my projects Properties\launchSettings.json file and noticed that the applicationUrl properties were different.
Change the values for applicationURL so they are the same
Close the project and close VS
Delete the hidden .vs folder (as mentioned in the accepted answer)
Start up VS as Admin
Your app should work fine.
I was having this issue with Visual Studio 2019 with a clean branch from master. Restarting the PC solved the problem.
My colleague said he is having the problem about 2 times a month and other tries for solutions did not work.
It could also just be that there are iisexpress.exe processes hanging around in task manager which were running on the same port.
I've just found a couple and killing them solved this problem for me without needing to delete any .vs folder or changing ports or anything like that.
I gave up, and chose to run the project as self hosted, instead of 'IIS Express' in the play/run drop-down box.
In my case, the problem was caused by the port for HTTP and HTTPS being the same:
The ports must be different:
In a solution if you have multiple projects using ASP.NET Core in Visual Studio 2017 and you are trying to use the same port number you will get this error. You must have unique port assignment in your solution.
Go here in your project: Properties/launchSettings.json open this file and edit the port numbers here. Note: This is where you change the SSL port (two places).
Reason: VS/IIS Express maintains bindings to all the ASP.NET Core projects in your solution that use IIS Express as the server. For example if you use Kestrel or some other server you will not have this problem. VS creates a new port for each app when it is created in the solution to ensure you do not have port conflicts.
If you are trying to use Azure AD registered applications reply ports and trying to "reuse" your app registration, you might think to simply change the "app's" port so that you don't have to register it in Azure; this will not work. If you are just testing apps and want to reuse a registration then you must make sure that the app you are currently working on is the ONLY one on the port - manually. If you need to test two or more apps then you must register them in Azure AD individually as you would in production.
What worked for me and it is really simple:
Right-click project
Properties
Debug
App URL: change port to 5000
Done, hope helps someone.
Changin https -> http in my applicationUrl solved this issue in my case.
I have solved this issue by
adding exclusion to file devenv.exe in windows defender (anti virus, Win10)
how to know this is the issue;
when you load project defender will notify in notification unauthorized changes blocked. if this is the issue just add the exception as above mentioned.
For me above solutions did not work
But changing the IIS Express Bitness to x64 worked
I encountered this issue. Running VS in admin mode solved this issue for me.
Go to properties - select debug tab - change the App URL - e.g. to http://localhost:57520/
Something else can be running on your port that interferes.
This worked for me!
For me with VS2019, faced this same issue on start running our project.
So right clicking on IIS Express icon in notification pane near by DateTime pane in our laptop/Desktop. It will show up all running application, at last can find Exit. Click Exit there and run your project should work. That worked for me, without closing VS19 project.
After playing with netsh configuration trying to make the server accessible from outside, I added a new iplisten entry. The IISExpress showed the error Unable to connect to web server 'IIS Express' which was fixed after deleting the iplisten entry using:
netsh http delete iplisten <ip-address>
You can view the current list of iplisten entries using
netsh http show iplisten
They require running an elevated (administrator) command prompt.
It seems like IISExpress has no error message in this a case.
If you're hard-coding a specific IP address (not localhost), check that it hasn't changed.
Tried all. didn't work above.
changing host in applicationhost.config fixed.
change localhost to 127.0.0.1
<binding protocol="http" bindingInformation="*:50740:127.0.0.1" />
<binding protocol="https" bindingInformation="*:44381:127.0.0.1" />
It works after I reenter username and password for the application pool's identity account
Setting "Enable SSL" to false in project properties\Debug section worked for me.
It may not completely direct your case, but I just had to restart my (windows) system. The diagnosis of #Turneye may very well be the reason and his solution might accomplish the same result.
I added the localhost option on the applicationhost.config file and run visual studio as administrator and it worked for me.
<binding protocol="http" bindingInformation="*:6873:localhost" />
<binding protocol="https" bindingInformation="*:44320:localhost" />
<binding protocol="http" bindingInformation="*:6873:192.168.137.1" />
Some times running visual studio as administrator solves this issue.
For me worked by changing the applicationUrl in launchsettings.json file to different port number and that url to be same for all places inside this file.
In my case (VS 2019), all I have to do is Rebuild the code before I re-run the app after each code modification.
P.S. I am coding server-side Blazor.
If you've used netsh http add urlacl url=http://localhost:<port>/ user=everyone to add a specific url acl using the problem port then you'll need to delete it with netsh http delete urlacl url=http://localhost:<port>/ user=everyone.
Another solution is to run Visual Studio as an administrator which allows it to override the urlacl.
I was facing the issue multiple times in VS2019, then I realized when I make small edits and restart the IIS Express this problem is more pronounced. Some of the discussion above about ports make me think since I was closing the app by just closing the browser. So I believe the port was not released and it failed the start next time around.
I started closing the debug by clicking the "Stop Debugging" button in the VS2019. The issue didn't occur again for me.
I solved this by restart my laptop.
Rebuilding the solution fixed this problem for me.
For those of you using .Net Core 3.x and still struggling, like myself, I finally after days of searching found a hint to the problem https://weblog.west-wind.com/posts/2020/Jan/14/ASPNET-Core-IIS-InProcess-Hosting-Issues-in-NET-Core-31.
In .NET Core 3.x InProcess hosting for IIS is the default. OutOfProcess hosting externally runs Kestrel.exe and has IIS proxying requests into the external Kestrel HTTP host. InProcess hosting uses a custom IIS Module that bootstraps a custom .NET Core host right into the IIS host process which provides better performance and a smaller footprint.
Changing to "Out of Process" (Right Click Project > Properties > Debug > Web Server Settings > Hosting Model), closing visual studio, deleting the hidden .vs folder (as described in previous comments), and then running IIS Express in VS finally worked. If you ever change it back to "In Process" for testing and it doesn't work, you'll have to delete the .vs folder again after you change it back and close the project.
If you're like me and that got you over one hurdle and into another....
My next issue was i was getting this error This webpage is not available (with error code "ERR_CONNECTION_RESET") when running a request to ping the server in powershell (Invoke-WebRequest -Uri:https://localhost:{port}/{endpoint}). This thread mentioning the error lead me to a thread that mentioned a missing iss express development cert, which mentions solving it by running ./IisExpressAdminCmd.exe setupsslUrl -url:https://localhost:{port}/ -UseSelfSigned in the IIS Express program files directory in an admin powershell terminal.
I'm also gonna post my first issue here when trying to run IIS Express from Visual Studio, which was Cannot find C:\Program Files\IIS Express\iisepxress.exe. IIS Express was for some reason installed not only in my Program Files (x86), but in my second drive (D:\Program Files (x86)). After realizing that there is just no way to change where Visual Studio is looking for IIS Express (even though it's also installed on the D drive), I uninstalled IIS Express (which is probably how my dev cert got removed), in RegEdit changed my Program Files directory back to the "C\Program Files" folder (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion > ProgramFilesDir key), and reinstalled IIS Express from Microsoft.
Finally, I can run my .Net Core API locally using IIS Express.
Good luck all!
Question says it all. I'm trying to write a Visual Studio addin (2012), and the experimental instance always launches without running anything in the addin. No breakpoints are hit in the main instance, nor does the addin get loaded by the experimental instance.
I should point out: it worked at one point once or twice, then I deleted the project since I thought it was the wrong kind of project, but ended up recreating it with the same name.
No amount of fiddling with "allowing addins to load" or resetting the experimental instance or cleaning the registry manually fixes the problem. I also tried looking for my addin dll, but it wasn't in the list. I'm totally out of ideas and possible search terms. Any suggestions?
I had the same problem as you and have just discovered the fix for me, it relates to the new "file properties" entry in the add-in project that gets supplied.
If you open this file which is in my case called "[App Name] - For Testing.AddIn" you'll see XML markup containing things like the AddIn friendly name, description e.t.c.
For me I found that I'd immediately renamed the output assembly for my project and this no longer matched that found inside this properties file:
<Extensibility xmlns="http://schemas.microsoft.com/AutomationExtensibility">
<HostApplication>
<Name>Microsoft Visual Studio</Name>
<Version>11.0</Version>
</HostApplication>
<Addin>
<FriendlyName>My Addin</FriendlyName>
<Description>My Addin description.</Description>
**<Assembly>E:\Workspaces\Scratch\MyApp\bin\MyApp.VisualStudio.Addin.dll</Assembly>
<FullClassName>MyApp.VisualStudio.Addin.Connect</FullClassName>**
<LoadBehavior>1</LoadBehavior>
<CommandPreload>1</CommandPreload>
<CommandLineSafe>0</CommandLineSafe>
</Addin>
I checked the name of the assembly and class names fixed them up, saved the file and hit debug and it all started working again! Hope this helps...
I had a similar problem... fought with it for quite a while, and eventually, absolutely randomly experimented with adding other configurations to the project (Configuration Manager) and also changing the framework.
One of the two magically helped. (I think it may have been the framework... though it makes no sense).
I am not saying that the same thing will work for you.
The random experiment was not really random: I got hold of a "debuggable" add-in off the web, and compared every single item in the project, solution and all other files, to find what could be different. This is my true suggestion.
If all else fails, you can also try to manually attach the debugger, see if you can make headway this way. [ that did not work for me, but it may provide valuable information, and... not all bugs are created the same. ]
Seems like there are different solutions to this problem but this finally helped me:
Changing <LoadBehavior>1</LoadBehavior> to <LoadBehavior>0</LoadBehavior> in the AddIn-file and put it manually in C:\Users[UserName]\Documents\Visual Studio 2012\Addins
Restarting Visual Studio (I use 2012)
Complete AddIn-file:
<?xml version="1.0" encoding="UTF-16" standalone="no"?>
<Extensibility xmlns="http://schemas.microsoft.com/AutomationExtensibility">
<HostApplication>
<Name>Microsoft Visual Studio</Name>
<Version>11.0</Version>
</HostApplication>
<Addin>
<FriendlyName>[Friendly Assembly Name]</FriendlyName>
<Description>[Description of the Addin]</Description>
<AboutBoxDetails>[About details]</AboutBoxDetails>
<Assembly>[Full path to the binary e.g. C:\Test\debug\test.dll]</Assembly>
<FullClassName>Test.Connect</FullClassName>
<LoadBehavior>0</LoadBehavior>
<CommandPreload>1</CommandPreload>
<CommandLineSafe>0</CommandLineSafe>
</Addin>
</Extensibility>
In my case I moved to a different developer machine where it was previously working on the old machine, but on the new machine I didn´t have any '[Assembly Name] - For Testing.AddIn' since I didn´t bother to check it in. I think the LoadBehavior is the difference between For Testing and the regular AddIn.
I had the same problem. Debugging worked until I closed all instances of Visual Studio. I then opened Visual Studio again and it said that the add-in that I had been debugging had stopped working. When Visual Studio asked whether to remove it, I said yes.
Apparently removing the add-in in this ray renames the "[AppName] - For Testing.AddIn" file to have an underscore appended.
To fix the problem, go into the add-in solution and look at the properties on the "[AppName] - For Testing.AddIn" file. Go to the folder where the file is located. Rename this file in the file system to match the name of the file in Visual Studio.
In my case, Resharper was the reason. Everything gets back to normal after disabling Resharper.
I installed a retail version of Windows 8 Pro. I downloaded and installed Visual Studio Express 2012. I asked for and received a developers certificate. Then I tried to create a hello world app.
From there I get a "Unable to Activate Windows Store App" message box when I try to debug the app. Most commentary on the web says delete build directories. This didn't work for me
Does anyone have a solution for how to fix this and debug my app?
This happened to me once too, but the deleting build directories advice fixed it. Specifically, you just need to delete the bin\Debug and bld\Debug folders in your projects. Their contents will be regenerated by Visual Studio when you rebuild. I assume that this is only one project since it's a Hello World app; otherwise I would ask if you deleted build directories from all projects in your solution.
You can also try running "Clean Solution" from the BUILD menu in Visual Studio.
I'm sorry...it's horrible if this is happening on a clean install as you describe.
I ran into the same issue, and tried rebuilding, cleaning, deleting temp files, rebooting the computer, etc... and nothing helped.
Then finally I made a release build then went back to debug. And now it works.
I have no idea what happened, nor if that really helped, but it's worth a try.
For me a RESTART of pc solved this error message.
For me the problem was that I created the app on a TrueCrypt mounted virtual drive and when I moved the project files to a normal drive then everything worked just fine. Weird.
I was getting the exact same error. In my case the culprit was a NuGet package. It had added an app.config file to the project and it was confusing VS. I removed the app.config file and it solved my issue.
I got the solution at Iris Classon's site.
This can be solved by Uninstalling the app from the start screen then again building the app from Visual Studio.
I had a similar problem, and the cause was creating the project on a USB thumb drive. Creating a project on a normal hard drive volume works.
this can happen when the application signing key (.pfx file) is missing.
Try the following:
Open the Package.appxmanifest file in Visual Studio
Go to the register "Packaging"
Select [Choose Certificate…]
Select the test certificate using [Configure Certificate…] [From File…], or create a new one using [Configure Certificate…] [Test Certificate…]
When using a test certificate, ensure that it is in the .gitignore file. There should be an entry like !**\*_TemporaryKey.pfx to include the key in Git.
Note: The certificate for release build should only be available to the build server and not included in Git.
Rebuild the project
This has happened to me in the past and I have always found that deleting the build directories resolves it.
However this time this is not working for me.
I have tried
- Rebooting
- Deleting build directories
- Running Build | Clean Solution in VS
- Renewing Developer Account
The only thing that will work for me is changing my Package name under the Package.appxmanifest
However I am not overly happy with this as a solution. I will keep investigating.
The issue might be caused because NuGet will try to add an app.config with binding redirects to Windows Store apps if it thinks it is needed. However, Windows Store apps don’t need app.config, and will actually fail to start with a very confusing error message if it is present.
And the solution in this case would be to Remove the App.config
This error generally comes when you try to deploy in debug mode.
I would suggest, deploy the app first in release mode and then try in debug mode.
This worked for me.
Making a new certificate works for me. For this, go to Package.manifest->Packaging, and follow the Choose certificate.... Click on Configure certificate and select Create test certificate. Give it a name and press OK.
Increasing the revision number of the package worked for me
Tried so many of the above fixes. Nothing worked (deleting bin, obj dirs, editing the manifest, editing the registry, changing package name, etc, etc.) My Avast antivirus software was running and so I uninstalled it completely. That was it. App now runs fine.
This sort of problems are common with Windows 8 Visual Studio. Such errors encounters when your developer license of Visual Studio has expired so you may want to renew or get a new developer license here's how you get that. How to get a developer license in Windows 8
And similar problem may also encounter with E_Fail issues here's how to solve Unable to activate Windows Store app E_Fail Issue
For me, the fix was a combination of two of these answers -
Renew the developer license (How to get a developer license in Windows 8)
And deleting the build directories (though I deleted more then the screenshot depicted) Delete the Build directories
NuGet will try to add an app.config with binding redirects to Windows Store apps if it thinks it is needed. However, Windows Store apps don’t need app.config, and will actually fail to start with a very confusing error message if it is present.
Solution:
Remove the App.config
and build again
For those who get a similar error but who are searching for a solution while debugging an IOT background app on a local machine specifically - you can find it here.
Using the search term "unable to activate windows store app the activation request failed with error" brought me here.
Because of Two things i resolved this issue.
Basically, we just need to delete the bin\Debug and bld\Debug folders in our projects. Those contents will be regenerated by Visual Studio when you rebuild project.
Just Restart the Visual Studio. And Clean Build and Rebuild the solution and RUN it.
Hope this helps.,
Playing with this issue for 3 days, tried every suggestions, nothing works. Until now!!!
The solution was this for me:
renew developer licence
build and deploy solution in Release mode (after this step it still not worked, but VS installed some packages in rpi)
start VS remote debugger with default account (http://:8080/#Debug%20settings)
configure remote device with Universal authentication mode (VS2017 -> Project settings -> debug -> target device: remote machine, authentication mode: Universal (unencrypted protocol))
...and now I can sleep.
Hope it helps somebody.
This gift was courtesy of Microsoft's automatic updates for VS2015 which was one of the 2 culprits:
KB3022398
KB3165756
It also broke SourceTree and other apps that draw the GUI - making an outline of the app but not drawing the contents.
For me changing the Package Name in Package.appxmanifest fixed the problem
In my case, the C# UWP app had a native library which failed in the application startup code, and called exit(1). The symptoms were identical to those in the question, though. Visual Studio would throw a message:
Unable to activate Windows Store app '88888888-6666-5555-4444-111111111111_abcdefgh!App'. The Acme.exe process started, but the activation request failed with error 'Operation not supported. Unknown error: 0x80040905'.
In addition, there was a message in the UWP app Windows log under Microsoft\Windows\Apps\Microsoft-Windows-TWinUI/Operational: event ID 5961, message:
Activation for 88888888-6666-5555-4444-111111111111_abcdefgh!App failed. Error code: Unknown HResult Error code: 0x80040905. Activation phase: COM App activation
Internally, the C# part would try to construct a native class instance from the App constructor, the native class constructor would encounter an unrecoverable error and bail. From the UWP subsystem standpoint, and from the debugger standpoint, though, this looked as something distinct from the mere programmatic exit. I'll leave this answer here, 'cause I've spent some time chasing various UWP failure scenarios instead of running under a native debugger.
I've replaced the exit() call with throw ref new Exception(E_INVALIDARG). At least this way the error manifests in the managed debugger, and the message is descriptive.
I've been having this problem a lot with a UWP Windows 10 app on Visual Studio 2019...for me the reliable workaround is to bump the Build number in the Package.appxmanifest file (Packaging tab). It's a huge pain...really hope Microsoft will sort this out soon
Any existing error in the code can also cause this issue. Make sure your previous version of the code is working fine. Compare the difference and make sure all looks good.
I was getting this error and nothing else worked so I had to dissect my program. Turns out I referenced a StaticResource in my App.xaml that didn't exist.
Seems like a silly error but you'd also think Visual Studio would pick up on something like that and throw a different error so if nothing else works, double check your application resources.
As suggested by #Iman in a comment, in the UWP project settings, enable "Compile with .NET Native tool chain".
(After trying just about every answer in this question)
When I run a Windows Azure web role on my local developer fabric, I get the following error:
The current service model is out of sync. Make sure both the service configuration and definition files are valid.
One of my colleagues hit this issue and after a bit of playing about, the problem was that the two service configuration files (cloud and local) had a different number of Settings.
When he updated the configuration files so that they were in sync it all worked.
A tip would be to use the GUI in Visual Studio to add new settings to both at the same time. The GUI can be accessed by right clicking the web role and selection properties. This should open up a window. Click the Settings tab on the left.
For me, this was caused by my azure project having been copied from one PC to another (going from Win 7 to Win 8.1 in the process). I am using VS 2013 Community edition on both, but I had upgraded from Azure 2.4 on Win7 to Azure 2.5 on the Win 8.1 machine.
If you unload the azure project and edit the csproj file, you just need to make a small edit (e.g. adding a comment) and save it, so it re-writes itself. This fixed it in my case (where I'd spent ages checking for errors in the CSDEF and CSCFG files). Once I re-saved the csproj file, it worked fine.
This happened to me because one of my cloud configuration files (.cscfg) was missing some key-value pairs that were defined in ServiceDefinition.csdef.
Going over the files manually was a pain. There's an easy way to discover the descrepancies:
In the Solution Explorer, right-click one of the Roles that make up
your Cloud Service and click 'Properties' in the context menu.
The Role properties window will open up grey with an error message saying:
"Invalid Service Definition or service configuration. Please see the
Error List for more details".
Open the Error List window and in some cases you
should be able to see a list of the specific discrepancies, complete with file
and property names.
I followed all the answers here and it still didn't work
eventually I restarted Visual Studio and it worked.
I believe the solution was the combination of one or more of the answers here + restarting VS.
What worked for me was to:
Make sure the Cloud Services .cscfg and .Local.cscfg files were identical (unless you need your Local.cscfg to have some differences for debugging purposes),
Make sure the .csdef file had definitions that matched the .cscfg files, and then
Close the project and delete its Cloud Services .ccproj.user file.
After reloading the project, all was well.
The error can occour when there is no actual fault in the service configurations.
If it occours and everything seems to be correct, instead of restarting visual studio, simply unload the azurecloud project (rightclick: unload proecjt
Please cross check your ServiceConfiguration.Cloud.cscfg and ServiceConfiguration.Local.cscfg files. My problem was, I added a configuration to Local.cscfg but forgot to add the same to Cloud.cscfg
Had this issue - no errors though. I have found that for some bizarre reason the if the setting:
<Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />
was commented out, then the workerrole would not launch.
For me, the issue turned out to be an inconsistency between the vmName value I had assigned to one of my roles in my various environments. I have a *.cscfg files for my development, test, and production environments. Each of these had a role definition that was supposed to be along the lines of
<Role name="HardWorker" vmName="SomeName">...</Role>
but one had an entry like
<Role name="HardWorker" vmName="SomeOtherName">...</Role>
and that, apparently, was enough to trigger the error.
My problem was incorrect certificate definition in csdef file.
For me the problem was that the Wifi I was using blocked the PORT Azure is using, changing Wifi solved that problem.
I just added xUnit to our test project (for the Asserts, we're still using MSTest as the framework) and immediately the test runs refused to execute any of the tests. This is the error message:
Failed to queue test run '{ .... }'
Test run deployment issue: The
location of the file or directory
'...xUnit.dll' is not trusted.
It took me a few tries to find the answer in Google, so I'm putting it here in case anyone else runs into the same problem. A detailed description can be found at this blog posting.
Basically, the fix invovles right-clicking on the dll file (xunit.dll for example) in Windows Explorer, going to Properties, and clicking "Unblock" at the bottom of the tab next to the 'Security' text. It seems that Vista / Windows 2008 will automatically mark assemblies that come from other machines or the internet as unsafe.
As a couple commenters have mentioned, you may also need to restart Visual Studio for this to take effect.
In my team we had the same problem.
Your solution didn't work, but this post by Charles Sterling did help.
We used the following line:
caspol -machine -addgroup 1 -url file://\\server/share/* FullTrust -name DevShare
After having this issue and burning hours trying to get "Unblock" to stick longer than a few minutes and/or figuring out caspol to no avail, I finally found a little tidbit via Google that the assemblies will be blocked again the next time you build or rebuild the project, since they're re-copied from their original source location. (I guess I never noticed that this happened before with references assemblies, but anyway...)
My fix for this was the following:
Copy all the needed DLLs to another
spot for safe-keeping
Remove the
references in Visual Studio
Physically delete the DLLs in the
bin folder
Unblock the DLLs
individually in the spot where they
were copied off
Add the references
back in Visual Studio from the
holding spot
Every subsequent build or rebuild worked fine afterward.
Running on an XP machine (even with .NET 3.5 SP1 installed) I was not able to get any of the other solutions listed here to work.
However working from the same post by Charles Sterling that Davy Landman references, I finally succeeded with this variation:
Run the .NET 2.0 Configuration tool (Settings... Control Panel... Administrative Tools... .NET Framework 2.0 Configuration)
Click down to "My Computer ... Runtime Security Policy ... Machine ... Code Groups ... All_Code"
Create a new code group with membership condition of "Zone"="Local Intranet" and assign the permission set "FullTrust"
Restart Visual Studio
After these steps I am able to run tests, including after restarts and rebuilds.
EDIT: as described in this answer, you may need to install the .NET SDK (which is different from the .NET framework) in order to have the .NET 2.0 Configuration tool on your system.
I had the same problem with moq. But would not 'unblock'. Every time I unblocked it, it was still blocked!?!?
I had to unblock the original zip file I downloaded. Then copy the DLL from the zip file again. It work after that.
It may seem really obvious now, but when I was clicking unblock the file was set as read-only.
Only after un-checking that attribute, applying, then selecting unblock did I actually get this working.
Give that a go.
:)
PS: I also deleted all the old dll's in my bin folder, just to make sure Visual Studio wasn't picking up the old one.
I had the same problem with downloaded DLLs blocked by Vista.
You need Administrator rights to get the "Unblock" button on the file's Properties.
I simply replaced the DLLs with the latest version from source control (TFS) where I had committed them before.
Go to file
Right click and select Properties
On the first Register click on Allow
I also tried opening the file in notepad++ and renaming it.
Slightly different approach, but it worked for me. The local file system then think it comes from the same machine.
It's not just the moq.dll that needs to be unblocked. The latest zip file includes an moq.xml and moq.pdb file - referencing the dll copies these other two files to the bin folders as well. If all three have not been unblocked the tests won't run, I found.