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.
Related
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).
The problem: My syntax highlighting and IntelliSense are broken. I have a C++ source file like this:
#include "stdafx.hpp"
#ifdef SOMETHING
do_some_stuff;
#endif
where stdafx.hpp (the precompiled header for the project) includes a .h file that says:
#ifdef DEFINE_SOMETHING
#define SOMETHING
#endif
and DEFINE_SOMETHING is defined in the project properties for the project (under C++ / Preprocessor).
Visual Studio is losing track, and displaying do_some_stuff; (which is actually lots of lines of code) in plain grey - I have neither syntax colouring nor IntelliSense.
The question: How can I either make Visual Studio get this right (unlikely) or switch off the fact that it's greying-out code that it thinks is #ifdef'd out?
(Rearranging the code is not an option - it's a large and complex system whose files are built in various environments, Visual Studio being only one of them. I'm using Visual Studio 2005, but I'd be interested to know whether this is fixed or workaroundable in a later version.)
If someone still interested - to turn off graying out #ifdef:
Go to Tools -> Options
Open Text Editor -> C/C++ -> Formatting
Uncheck Colorize inactive code blocks in a different color
In VS19, it's Tools / Options / Text Editor / C/C++ / View / Inactive Code / Show Inactive Blocks.
Following previous answer of aousov I check my VSCode and found this setting:
C_Cpp: Dim Inactive Regions
Controls whether inactive preprocessor blocks are colored differently than active code. This setting has no effect if IntelliSense is disabled or if using the Default High Contrast theme.
in Extensions / C/C++
This may be related to the version you are using (in my case 1.46.1).
Best,
Geoffroy
The problem you describe is par for the course in VS 2005. It is fixed in Visual Studio 2010 and later due to the completely redesigned Intellisense system. This is not directly applicable to your problem, but here's some info on the underlying architecture: http://blogs.msdn.com/b/vcblog/archive/2009/05/27/rebuilding-intellisense.aspx
There are some things you could try, and some project structure changes that can help minimize the problem's frequency, but whatever you do will be hit or miss, and the problem will eventually resurface again regardless. The only real solution is to use a newer IDE.
You can continue to use the VS 2005 build tools by installing VS 2010 along with Daffodil (http://daffodil.codeplex.com), then build your projects with the v80 platform toolset in VS 2010. This makes the migration fairly straightforward, with no need for any source code changes.
Since #define SOMETHING is defined inside stdafx.hpp, indicating that it's always defined since DEFINE_SOMETHING is defined in project configuration, would it be out of the question to also define SOMETHING explicitly in project configuration?
I used to have similar issues in VS2005 and 2008, and redundant explicit definitions sometimes helped.
I fixed this (in VSCode) by changing C_Cpp.default.intelliSenseMode
"C_Cpp.default.intelliSenseMode": "windows-gcc-x64"
I am building an ARM project on a micro-controller. Its not 64 bit either. But this does parse the directives correctly.
For Science I tried Widows-gcc-ARM and that also correctly lit up the regions that are truly active. I also know for a fact that gcc is setup and configured on my windows machine, and while I have clang and msvc, I dont use them and dont know that they work- so it could be why gcc works better for me.
You can experiment with this setting, but I am fairly certain the resolution resides in this option.
I do not know the equivalent VS option, I am sorry.
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.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
How do you count the lines of code in a Visual Studio solution?
How can I show the code metrics window in Visual Studio 2008 Professional SP1? I'm looking to see how many total lines of code my project is for school and I can't find it.
The help file said to go to View->Other Windows->Code Metrics, but this option is not available to me. I also tried right-clicking the project in the Solution Explorer to see if there was an option but there wasn't.
Where is this mythical unicorn of a feature? If the Pro version doesn't have this feature has anyone found a simple external method to count the lines in all .cs files in an automated way?
You don't need 3rd party tools, just press CTRL+SHIFT+F, and in the window that pops up choose "use regular expression". Use this Regular Expression:
^:b*[^:b#/]+.*$
For Visual Studio 2012 and above the regular expression is:
^(?([^\r\n])\s)*[^\s+?/]+[^\n]*$
Code Metrics is only available in the Team System versions of Visual Studio 2008. If you have an Express Edition, Standard, or Professional you're out of luck.
See comments and screenshots here:
http://blogs.msdn.com/fxcop/archive/2007/10/03/new-for-visual-studio-2008-code-metrics.aspx
http://blogs.msdn.com/somasegar/archive/2007/10/04/code-analysis-features-in-vs-2008.aspx
DPack does this. After installing, just go to Tools -> DPack -> Solution Statistics...
http://www.usysware.com/dpack/
I don't have that feature in my VS2008, so a few months ago I implemented a quick and dirty windows app that counts the number of CRLFs in my C# files. Granted, this counts empty lines, and lines in files generated by VS, but with a bit of tweaking, I am sure you could make it generate a good count. Here is the operative code in the Windows Form; the dlgFolder control is the FolderBrowserDialog control:
if (dlgFolder.ShowDialog() == DialogResult.OK)
{
int totalLines = 0;
string[] fileList = Directory.GetFiles(dlgFolder.SelectedPath, "*.cs", SearchOption.AllDirectories);
for (int x = 0; x < fileList.Length; x++)
{
string[] sourceCodeLines = File.ReadAllLines(fileList[x]);
totalLines += sourceCodeLines.Length;
}
MessageBox.Show(String.Format("There are {0} lines of C# code in the folder{1}",
totalLines.ToString(), dlgFolder.SelectedPath));
}