We have Visual Studio 2010 SP1 and Async CTP (SP1 refresh) installed.
A solution with projects that use async/await keywords builds OK when build from VS IDE.
Also when built with devenv /build "Debug" solution.sln everything is OK.
However msbuild #commands.rsp solution.sln reports:
File.xaml.cs(123): error CS1993: Cannot find all types required by the 'async' modifier. Are you targeting the wrong framework version, or missing a reference to an assembly?
commands.rsp looks like this:
/nologo
/p:Configuration=Debug
/m:3
/fileLogger
Any clues?
Please, refer to the discussion here: http://social.msdn.microsoft.com/Forums/uk-UA/async/thread/3d491cb0-a19f-4faf-80a6-5fd05e4e06db
There are 2 points to be clarified in order to understand better your problem:
Environment: did you install VS11 side-by-side with VS 2010+Async CTP?
Your project: do you have XAML with user controls and "clr-namespace" in your project?
I will cite the preliminary conclusion by SERware from the discussion on the MS forum:
I think it has to do with the order in which the XAML projects
compile assemblies when referring to classes of the library itself. In
this case, the XAML Loader try to compile this classes before having
reference to the Async CTP library. So, the keyword "async" is not
recognized.
Personally I am going to see whether it is possible to split the assembly in order to resolve the order of the compilation of the dependencies in XAML
Added after further investigation:
As I have found out, the explanation is even more disappointing: the .NET 4.5 (Beta) replaces the .NET 4.0. Besides, the signatures of the async/wait related types have been internally changed. Therefore there is no way so far to use simultaneously VS 2010+AsyncATP and VS11 Beta. – Yuri S. 2 mins ago
I was hit by this myself and for various reasons I can't upgrade the projects to .NET 4.5 so I had to develop a workaround.
Since this is only a problem for XAML projects that has a xmlns declaration pointing to itself I'm able to use async on all the other projects that are referenced. This means my architecture is still utilizing async/await and is prepared for the move to .NET 4.5 later.
But in the affected XAML projects, I just manually implement (poorly) the await things otherwise done by the compiler.
So code that was this clean before:
try
{
var foo = GetFoo();
foo.DoStuff();
var data = await foo.GetDataAsync();
bar.WorkOnData(data);
}
catch (Exception ex)
{
// Logging, throw up a popup, whatever...
HandleError("Failed to get data", ex);
}
Now becomes this:
var foo = GetFoo();
foo.DoStuff();
var getDataTask = foo.GetDataAsync();
getDataTask.ContinueWith(t =>
{
if (t.IsFaulted)
{
// Logging, throw up a popup, whatever...
HandleError("Failed to get data", t.Exception);
return;
}
if (t.Status == TaskStatus.RanToCompletion)
{
bar.WorkOnData(t.Result);
}
});
Not ideal of course, and this is the exact thing that async/await was created to solve. But it does work as a short-term workaround at least for simple uses of await.
Related
I tried to create an ASP.Net website using F#, .Net-Core 3, Ionide, and Visual Studio Code however, when I tried to set a breakpoint in an F# file it didn't get hit.
But when I put an
assert false
In front of my breakpoint, I get the exception, and the breakpoint gets hit afterward.
I have also tried the same in Visual Studio where the assert correctly breaks, but when continuing, it doesn't hit the breakpoint, even though VS Code does.
In VS Code, this doesn't work:
let x = 4 // <- Breakpoint
But this does:
assert false
let x = 4 // <- Breakpoint
I also get this warning when starting regardless of whether I add the assert or not.
Breakpoint warning: No executable code of the debugger’s target code type is associated with this line.
Possible causes include: conditional compilation, compiler optimizations, or the target architecture of this line is not supported by the current debugger code type.
What could be the cause, and how could I fix it?
In the end, the problem was the complex inter-project dependencies I had.
ASP.Net Project (F#)
Migration and DbContext Project (C#)
Unit-Test Project (F#)
DbContext ASP.Net shared objects Project (F#)
I solved the problem by keeping the Migration Project but moving the DbContext into the ASP.Net Project. So instead of a reference from the Migrations to the ASP.Net Project, I changed it to the other way around. That also allowed me to move the shared objects to the ASP.Net project and delete the Shared Object Project.
So this is what it looked like afterward
ASP.Net and DbContext Project (F#)
Migrations Project (C#)
Unit-Test Project (F#)
Although I didn't do it to solve this problem, it solved it as a side-effect.
I hope this will help someone else when they experience the same or similar problem.
We are utilizing Microsoft Fakes with Visual Studio 2013. After updating to Visual Studio 2013 Update-4 or Update-5, we are getting ShimNotImplementedException's in our tests.
We have followed instructions found in other SOF questions and turned off the SpecificVersion of our Microsoft.QualityTools.Testing.Fakes references. This allows a compile but the tests still fail when run.
The hint we needed to solve this was found in MSDN forums.
The underlying issue is that the legacy tests did not define specific methods
on the ShimXXX object that the code based is using. Under version 11
all is well; version 12 is a different matter.
The stack trace for the ShimNotImplementedException gave the needed information on the missing property/method:
Microsoft.QualityTools.Testing.Fakes.Shims.ShimNotImplementedException
at $Func`2NotImplementedf5b9281e-32b0-4bf3-9079-6a54470670de.Invoke(SiteContext arg1)
at Sitecore.Sites.SiteContext.get_Database() //THIS IS THE PROBLEM PROPERTY
at Sitecore.Ecommerce.ShopContext..ctor(SiteContext innerSite)
at ActiveCommerce.UnitTest.ProductStockManagerTests.get_MockShopContext()
at ActiveCommerce.UnitTest.ProductStockManagerTests.GetAvailability_AlwaysInStock()
Adding the missing property to our shim construction solved the issue:
return new Sitecore.Ecommerce.ShopContext(new ShimSiteContext
{
PropertiesGet = () => new NameValueCollection(),
DatabaseGet = () => null //ADDING THIS SOLVED THE ISSUE
});
I ran in to a similar problem after upgrading several of our projects from .NET 4 to .NET 4.5.2 using Visual Studio 2015. All the sudden several previously passing tests started failing. The common denominator was that all of the tests were using Shims to mock registry access.
What appears to have happened is that something changed in the handling of the Dispose method. Originally I had not implemented a Dispose method on the RegistryKey shims. That didn't seem to cause any trouble running under .NET 4. However after the switch to 4.5.2, it is implicitly being called all the time.
The solution was simple: I just added a stub for Dispose.
Microsoft.Win32.Fakes.ShimRegistryKey.AllInstances.Dispose = (key) => { };
The tests now pass again.
Note that setting it to NULL did not solve it for it. There has to be a method.
Recently installed new TS version into VS2013 and tried to use protected modifier.
However TS validator shows me an error (and underlines protected word with a red line.
I get an error like
Use of future reserver word.
; expected
looks like it's looking into old TS definitions.
Checked the project file and there is 1.1 version of TypeScript.
also running tsc -v produces 1.3.0.
Does somebody of you guys experience that?
What i'm missing and what to do to fix that.
Thank you a lot for any help.
export class SomeClass {
protected metadata: Metadata;
protected subItems: SomeClass[];
constructor() {
}
}
thank you all guys. for your answers!
the reason was (oh, what's the shame =) ) the ReSharper.
It's validation was showing that error, suspending it i'm getting no errors now.
Looks like JetBrains guys should update their definitions like Web Essentials did.
As they aren't compatible with new TS version, 1.3. And no updates pending as for now.
Hope, it'll be useful for somebody else.
The answer to your question then is ReSharper 9.0 EAP.
It supports TypeScript 1.3 features: 'protected' modifier and tuples.
You're welcome to try it. Though, yes, it's a pre-release version, so overall stability is not strictly guaranteed.
Are you building from within Visual Studio, or from the command-line? What with different versions of the SDK being installed, as well as potentially the NPM package globally (if you've ever installed that), it can get quite messy as to which version gets picked up. For example, if I run 'where tsc' from the command prompt, I get the below hits (and this is without the 1.1 SDK on the path, though I am in the bin folder for testing the latest bits)
S:\src\TypeScript\bin>where tsc
S:\src\TypeScript\bin\tsc
S:\src\TypeScript\bin\tsc.js
C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0\tsc.exe
C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0\tsc.js
C:\Users\billti\AppData\Roaming\npm\tsc
C:\Users\billti\AppData\Roaming\npm\tsc.cmd
Can you verify via "where tsc" the locations and order you PATH is resolving the 'tsc' command?
That said, if you're building from within a VS project, it should locate the latest SDK via the build target. Does this also occur with a new TypeScript project (where the latest version and targets file should be referenced)?
Failing that, and I hate to say it... ready... did you try rebooting? :-) Sometimes updates to the PATH etc.. after an install don't get picked up until processes restart, and things like MSBuild can actually linger waiting for the next build as a perf optimization, rather than exit once the build is done (and thus may not pick up environment changes immediately).
It didn't work for me too. What I did to fix it was installing VS2013 Update 4 and after that, I executed the TypeScript 1.3 setup again and did a repair.
Also, you should make sure you don't have <TypeScriptToolsVersion>1.0</TypeScriptToolsVersion> in your csproject defined. Set it to 1.1 (not 1.3) or remove it entirely (then it will use the latest one). Hope that helps!
You can determine whether the issue is related to Visual Studio pointing at the wrong TypeScript version by following these steps.
Place this example code in C:\Temp\app.ts
interface Metadata {
something: string;
}
export class SomeClass {
protected metadata: Metadata;
protected subItems: SomeClass[];
constructor() {
}
}
export class OtherClass extends SomeClass {
constructor() {
super();
this.metadata = null;
}
}
var x = new SomeClass();
// Not allowed
// x.metadata = null;
Run the command:
C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.1>tsc --module amd c:\Temp\app.ts
Taking care to ensure you are pointing at the 1.1 folder in the TypeScript SDK folder.
The output should be:
C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.1>
i.e. nothing, except you now have an app.js file.
You can also re-run the test after uncommenting the x.metadata = null; line - at which point you should get the error:
c:/Temp/app.ts(22,1): error TS2445: Property 'metadata' is protected and only accessible within class 'SomeClass' and its subclasses.
Next Steps...
If the above fails, please supply details of the problem.
The only real answer we could give though it remove it and check the 1.1 folder is gone before re-installing it by fetching the installer fresh from the Microsoft website (perhaps you have a bad installer or there was some problem during installation?) You may also want to check that you are on Visual Studio Update 4, as I am testing it on Update 4.
If the above worked as expected, your Visual Studio is not pointing at the correct version.
This could be because of the project file as Dick van den Brink has correctly mentioned. Check that you have <TypeScriptToolsVersion>1.1</TypeScriptToolsVersion> and that it is the only element with this name.
It can also be down to any Visual Studio extensions that may be messing with your TypeScript (for example, if you had a really old version of Web Essentials - in which case, update it - if it is some other extension, try disabling it).
I'm using VS 2010 Professional (On Windows 7 Professional 64), writing with WCF 4.0.
I have the following code:
if (responseMessage.StatusCode == HttpStatusCode.NotFound)
{
throw new ContentNotFoundException(contentId, SSPErrorCode.PartnerRestGetStream404);
}
When attaching the debugger to the process, having set a breakpoint at the "if" statement or before that, while the condition is false (responseMessage.StatusCode is 'OK'), the debugger steps into the "if" statement. It then steps over the "throw" statement without doing anything, then continuing on with the code.
I've tried:
Restarting VS, logging out my Windows user, rebooting, cleaning the solution, building it again, rebuilding it, recycling the application pool, resarting IIS, adding more code inside the "if" statement and inside the condition - nothing worked so far.
There must be a cache somewhere which I can clean to get rid of it, but what, and where?
Googling this I only found http:--social.msdn.microsoft.com/Forums/en-US/vsdebug/thread/d4b70fd7-b74a-42ce-a538-7185df3d3254/, so I tried manually setting the breakpoint, and it didn't break in this class, although the same did break in other classes.
I would love to fix this without reinstalling VS. Thank you in advance!
Update:
Since I put this up and could not find an answer, I moved on with my project.
I stumbled upon this issue, reported by John MacIntyre on this post, which ends up with a simplified example:
using System;
namespace IEnumerableBug2
{
class Program
{
static void Main(string[] args)
{
if (new object() == null)
throw new Exception();
try { } catch { }
}
}
}
Update #2:
Note that my Method also has a try-catch statement in it, a few lines after the 'if' statement.
I've just tried reproducing this bug again, and failed. I'm going to leave the question on stackoverflow for others who might need it, but, as I wrote, I am no longer able to reproduce the behaviour.
I am experiencing this problem too, but slightly different.
Here's my code:
string lockCode = Guid.NewGuid().ToString();
bool alreadyLocked = string.IsNullOrWhiteSpace(lockCode);
if (alreadyLocked) {
throw new Exception("already running");
}
try {
PerformTask(task);
}
finally {
UnlockTask(task, lockCode);
}
As you can see, the lockCode string is always assigned with a Guid value. The debugger steps into the 'if' scope, although it shouldn't. The exception isn't thrown.
I am running Visual Studio 2010 SP1 on Windows 7 64-bit with ReSharper 6.0.
Microsoft Visual Studio 2010
Version 10.0.40219.1 SP1Rel
Microsoft .NET Framework
Version 4.0.30319 SP1Rel
Installed Version: Premium
This happens to me with an ASP.NET application on framework 4.0.
I tried running the repro code posted here on a different project on my machine but could not reproduce the issue.
Also, I have deleted the Shadow Copy Cache for the .NET Framework on this path:
C:\Users\username\AppData\Local\assembly
I deleted the VS2010 symbols cache directory, and the Temporary ASP.NET Files.
I restarted my computer, cleaned the whole solution and rebuilt everything.
No clue why this happens.
Workaround: If I remove the 'try-finally' part from the method, or extract the throw statement to a different method, the debugger steps over the 'if' scope correctly.
Sorry for not posting a real solution to this, I hope this helps either isolate the problem or work around it.
Today I also experienced this issue. The following code solves the problem, with the advantage of not compiling the workaround on release builds:
using System;
namespace IEnumerableBug2
{
class Program
{
static void Main(string[] args)
{
if (new object() == null)
throw new Exception();
#if DEBUG
bool workaround = true; // dummy instruction
#endif
try { } catch { }
}
}
}
While stranger things have in fact happened, I highly doubt that this is a bug in the debugger or bad bad VS installation.
I think something must be happening that you're not interperting correctly. Did you put the expression "responseMessage.StatusCode == HttpStatusCode.NotFound" into the Debug Watch window? What does it return? Is it possible StatusCode is returning a different value each time? Did you try evaluating it several times to make sure it is consistent?
The only way I could imagine this happening is if the code was changed, and when prompted whether or not you want to debug the source file even though its version does not match, you answered Yes. This would explain why you can skip over the "throw" line without it doing anything - you're not debugging the actual code you're seeing, but an older version of it. To fix this, rebuild everything, and never say yes when prompted if you want to debug even though there is a version mismatch - it is way too confusing!
I've downloaded the WTL 8.0 package and come to find the scripts to install App Wizards don't support VS 2010.
Does anyone know of updates scripts to support installation in VS 2010?
Thank you!
The AppWizard for VS2010 above has two small glitches (however they might deter people from using WTL with VS2010). These are very easy to fix:
1) [Output Directory] and [Intermediate Directory] in new project properties are not followed by a backslash ('\').
To fix:
file: .\AppWiz\Files\Scripts\1033\default.js
I have replaced:
if(bDebug)
{
config.IntermediateDirectory = 'Debug';
config.OutputDirectory = 'Debug';
config.ATLMinimizesCRunTimeLibraryUsage = false;
}
else
{
config.IntermediateDirectory = 'Release\\';
config.OutputDirectory = 'Release\\';
config.ATLMinimizesCRunTimeLibraryUsage = true;
}
with
// Add generic configuration details
config.IntermediateDirectory = '$(SolutionDir)$(Configuration)\\';
config.OutputDirectory = '$(Configuration)\\';
config.ATLMinimizesCRunTimeLibraryUsage = !bDebug;
2) Some WTL headers are missing in newly created projects.
The symbol WTL_USE_CPP_FILES seems to be missing when the template stdafx.h file is parsed, as a result a bunch of header files are not included in new projects.
Again in .\AppWiz\Files\Scripts\1033\default.js, I have added:
// Add WTL_USE_CPP_FILES to all projects
wizard.AddSymbol("WTL_USE_CPP_FILES", true)
just below line 41 (so that the lines are always included). This seems to do the trick.
I've never looked at VS appWizards before (or js for that matter), so I can't guarantee the workarounds are concrete. It seems pretty straighforward though & I've been using WTL with VS2010 with no problems since I've made those changes...
WTL is awesome btw - many thanks to the folks who still maintain it!
Cheers,
Yiannis
WTL 8.0 was released in june 2007 so couldn't possibly support VS 2010.
You may download the current work in progress WTL 8.1 AppWizard from http://wtl.svn.sourceforge.net/viewvc/wtl/trunk/wtl/Wizards/AppWiz.tar.gz?view=tar and the matching library files from /include.tar.gz?view=tar.