I am wondering if Illegal syntax error is expected in the code window or its just me? It just not recognizes code directives <# #> and gives illegal sytax error everywhere I have c#scripts embedded.
Eg:
<## template language="C#"#>
This single line gives me 3 syntax errors
At first occurrence of '#' says Illegal syntax. Expecting valid
start name character.
At 'template' it gives me error *Missing
attribute value on attribute 'template'.
At 2nd occurance of '#' it
give error *Character '#', hexadecimal value x023 is illegal in xml
namespace.
Dispite of this syntax error, my biml scripts complies without any problem, unless there is a genuine problem. This is so annoying to write code especially when I am debugging to fix genuine code.
Is this expected? can we get rid of this? I have installed 1.7.0 version of BIDSHelper (which is latest in downloads) and using SSIS 2012.
BIDSHelper does not correctly check the syntax for code snippets. As far as I am aware there is no solution to this using your current set up.
If you upgraded your SSDT (as 2012 is currently not working) you could install BimlExpress instead which has all the same features as BIDSHelper (regarding what it can do with Biml files) and has proper syntax highlighting and error checking.
Further info here: http://www.cathrinewilhelmsen.net/2016/04/21/get-started-bimlexpress/
Related
I am updating a project to compile with VS2019 and turns out that importidl is no longer supported in VS2019 ( 16.9.2
). Comparing the generated .tlb prior to updating to VS2019 and after the binary file is much smaller resulting in a broken COM interface.
The error I am getting is C2337 'importidl':attribute not found.
The importidl is surrounded by a warning suppression:
#pragma warning(disable: 4467)
[ importidl(COM\\dummy.idl) ];
#pragma warning(pop)
C4467: usage of ATL attribute is deprecated
The Microsoft documentation leads to believe that imporidl had not been deprecated or removed. However, it has been last updated 2 years ago and the warnings and errors are leading me to believe that there is a discrepancy on the documentation.
What is the alternative to go around the removed importidl?
In order to fix this issue with VS2019, I added a /permissive flag to the command line option. Setting the conformance mode to "No" along with the std:c++latest did not work. std:c++latest is probably overriding /permissive.
Keeping the conformance mode to Default, with the latest /std:c++latest language standard and adding /permissive as an additional Options to the command line property goes around the error C2017 Importidl attribute not found.
I'm using PhpDocumentor (1.4.4) & NetBeans (7.1). When I generate the php documentation I get an error/warning on the top of the documentation (and in documentation in certain places too):
"Strict Standards: Only variables should be passed by reference in ..."
Does anybody know why is this problem?
Formerly (not on this computer) I didn't get this message.
The root cause here is that phpDocumentor itself if PHP4 code. I'm guessing you are executing it on PHP5, and are thus seeing runtime notices based on your error reporting level in php.ini.
This is nothing to worry about with regard to using phpDocumentor, nor is it something to worry about in your source code that you are documenting.
PHP Documentation states:
The following things can be passed by reference:
- Variables, i.e. foo($a)
- New statements, i.e. foo(new foobar())
- References returned from functions
No other expressions should be passed by reference, as the result is undefined.
This has been the case since PHP 4.0.4. Most likely your source code is out-dated and needs changes.
At last the solution:
I used smarty themes (HTML:Smarty:*) and there was no errors.
Solved.
I recently installed Chirpy v2.01 for Visual Studio 2010 and am very excited about the features it offers. I'm running into some issues in the LESS domain, however.
As a first step, I copied over my existing .css file to a new LESS file. I immediately am getting two errors. The first is due to a CSS "filter" property that I have set:
div.someClass {
filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#aaaaaa', endColorstr='#000000');
}
This apparently is because the filter value is not technically valid css. LESS has a workaround for this, via escaping. Adding a tilde in front of a quoted section tells LESS to keep the value as-is. The following change should resolve the issue:
div.someClass {
filter: ~"progid:DXImageTransform.Microsoft.gradient(startColorstr='#aaaaaa', endColorstr='#000000')";
}
Upon saving the file, I still receive an error in the visual studio error console along these lines:
Error 54 Expected '}' on line 2 in file 'C:\Users\Administrator\Projects\Project\Content\test.chirp.less':
[1]: body {
[2]: filter: ~"progid:DXImageTransform.Microsoft.gradient(startColorstr='#aaaaaa', endColorstr='#000000')";
----^
[3]: } C:\Users\Administrator\Projects\Project\Content\test.chirp.less 2 5 Project
The .css files are never generated so long as this error comes up. I came across the following site that seems to describe the issue I'm having, but in a more generic DotLess .NET package. I tried adding this package to my project, but it didn't make a difference. It also looks like it relies on the server to handle the .less to .css conversion, instead of the IDE, as chirpy does.
The second error that I constantly receive, though it doesn't seem to actually stop the generation of the .css files, is the following:
Error 53 Fatal error, cannot continue: null cannot be converted to an object C:\Users\Administrator\Projects\Project\Content\test.css 1 1 Project
I'd really love to use the LESS functionality that Chirpy offers, but until I can figure out why these errors are happening, I'm limited to using it for mash.
you have to understand that Chirpy is simply using dotlesscss internally to transform the less into css.
So any bug in dotless also applies to Chirpy.
We have patched that bug quite recently and a new dotlesscss version is upcoming.. But how long it will take until Chirpy updates to the new version is up to the Chirpy developers..
greetings Daniel
I wrote a similar VS extension that compiles less but it uses less.js directly and doesn't depend on dotless. Check it out.
The MSDN documentation for CommitTransactionAsync indicates it may produce an ERROR_PENDING error code. However, this error code does not seem to be defined in winerror.h, nor any other header reachable from ktmw32.h or windows.h (using the version of the Windows SDK included in Visual Studio 2010). In fact, I cannot find a single file containing the text ERROR_PENDING anywhere in the Windows SDK 7.1; manually going through the list of System Error Codes doesn't reveal it either. Where can I find the definition of this elusive error code?
Experimentation shows CommitTransactionAsync to produce ERROR_SUCCESS - is this a simple matter of the documentation being wrong?
It's a doc bug. #flashk's guess is correct: it can produce ERROR_IO_PENDING. I am submitting a bug to the doc owner today. Thanks!
Is there a "call stack" for compiler errors in Visual Studio 2005 (C++)?
For example, I am using a boost::scoped_ptr as the value in a QHash. This is however causing the following compile error:
1>c:\qt\include\qtcore\../../src/corelib/tools/qhash.h(743) : error C2248: 'boost::scoped_ptr<T>::operator =' : cannot access private member declared in class 'boost::scoped_ptr<T>'
From the build output I know which of my source files is causing the error and the line number in the qhash.h that is causing the error but I am trying to track down the line number in my source file that is generating the error (hence the "call stack" idea).
Please note, I am not looking for the solution to the problem of using a scoped_ptr in a QHash but the problem of tracking down where compile errors are generated. This would also be useful for helping track down weird warnings. More often than not I run into this problem when using templated classes.
Thanks!
Sometimes with strange errors it helps to preprocess the file and look at that output. With VS look for "Generate Preprocessed File" under preprocessor settings (or set the /P switch). This will generate XXX.i from XXX.cpp which may help you figure out the problem.
Make sure you turn off the switch after, with this option turned on it won't generate an obj file.
If you look at the build output, you should see which project and which .cpp file was being compiled when this error occurred.
There is really no notion of "call stack" here, because the compiler processes one source file at a time. You have a compiler error in the header file, so you need to find out which source file including that header was being compiled.
These types of errors can be hard to track down. Usually I end up comment out code and finding the offending line and working from there. After doing it a while you will learn to better read the error messages and understand what tripped up the compiler. As it stands the compilers error messages are just horrible.
In this case it is saying that you have an object of type boost::scoped_ptr<T> that it is trying to copy but the class won't let you (operator= and the copy ctor are both hidden). So you need to look at how the class is used and see why it is trying to copy it. Maybe a scoped_ptr isn't what you need. Maybe you need a shared_ptr?