I`m a new guy to c# and I try to add a some code to a certain class in my c# project in order to remove some characters from a string. These lines of codes are not executed at run time and the debugger steps over it.So,
1) How to make the new lines added to an existing project execute?
2) Is there a property in Visual studio 2005 that prevents developers from changing existing code?
3) Is it some Property related to the c# project that specifies a privilege of code change?
you should try cleaning your project and rebuilding it, sometimes visual studio is stupid and does not rebuild all the assemblies. i find that this fixes this problem about 80% of the time (if it's not my code, that is)
1) Just rebuild entire solution
2) No, as far as I know
3) No, as far as I know
Check to make sure you are not returning the a value before the added lines. If you hit a return prior to getting to those new lines that will exit the function and your new code will never execute.
Since you mentioned string, are you assigning the output back to the variable?
E.g.
string aStr = " abcdefg ";
aStr = aStr.Trim();
If you only do aStr.Trim(), you won't see the "update".
"\0" has a particular meaning in C# strings. Are you actually trying to remove the null character, or are there literal backslashes and zeroes?
If you're trying to remove a backslash and then a zero, try this instead:
string sMailMsg = eMailMsg.ToString().Replace("\\0", string.Empty);
Related
I am reading a long text file containing a sql query using StreamReader then using StringBuilder to create a string that gets run against a database. Once the string is created I checked the value and three dots ... appear within the string causing the query to fail when I run it against the database. Why is this happening? What can I do to keep it from happening?
string script;
if (File.Exists(path))
{
using(StreamReader sr = File.OpenText(path))
{
StringBuilder sb = new StringBuilder();
while(!sr.EndOfStream)
{
sb.Append(sr.ReadLine());
}
script = sb.ToString();
}
}
UPDATE: I should add that the three dots appear at character position 16384 every time. Not sure of the significance of this
UPDATE: It appears the string is being truncated at runtime. the file contiains 48080 characters but is being truncated in the middle at position 16384 making the string variable 32768.. Is this the max character count for a string?
I have a definite answer for you: Microsoft says that what you are experiencing is a bug in Visual Studio 2015. They have released an "Update 2" for Visual Studio 2015 that is reported to correct the issue.
I am trying to get this update installed by my admin, but in the meantime, a feasible workaround is to load the text in the JSON Visualizer instead. It will show an error that it is, of course, not valid JSON since it is SQL, but it will display the whole text of the string.
Download Update 2 from here:
https://www.visualstudio.com/en-us/news/vs2015-update2-vs.aspx
See the bug report here:
https://connect.microsoft.com/VisualStudio/feedback/details/2016177/text-visualizer-misses-corrupts-text-in-long-strings
I had the same problem while I was debugging the very long query string.
It turns out, Visual Studio(mine is 2015) Debugger will truncate long strings after certain amount of characters for ease of reading. So even though you are seeing three dots(...) in Text Visualizer, actual value doesn't have that three dots.
To my knowledge, visual studio 2012 debugger doesn't add three dots. I haven't found a way how to turn the feature off in VS2015, but you can use html visualizer or json visualizer as alternative solution.
I have a feeling that you are checking the values in your debugger, where the long query text is being partially shown and ends with an ellipsis (...)
Again guessing here, but seems like you join your lines of SQL into one single line, and if the lines in the file do not end with whitespace character, then the query will get messed up. Probably that is the reason why your SQL query does not work.
By the way, you can write the code you have far more succinctly as below
if (File.Exists(path))
script = string.Join(" ", File.ReadLines(path));
When I have simple wrap enabled on Wrap invocation arguments, I often end up with a formatted line like:
string.Format(
"example string tralala {0} {1}",
foo, bar);
no combination of settings I find prevents this line break other than enabling chop if long. unfortunately that can be a bit of a line hog (it forcibly makes each argument take a line if a function call takes up more than your max word-wrap space).
Is there any solution to this that I am overlooking?
In Resharper 9
Go to Resharper(from Visual Studio Menu)->Options->Code Editing->C#->Formatting Style->Line Breaks and Wrapping
and Uncheck Wrap Long Line from Line Wrapping option
There are a few settings you can use to format your code just the way you like it in re-sharper. in Visual Studio Go: Tools>Options>Re-sharper and click the Options button there again.
Then under the Code Editing section, under c#>Formatting Style. You can use one of the following settings:
Prefer wrap before ( in declaration\invocation
Prefer warp after ( in declaration\invocation
Or set the wrap invocation argument to either (this is most likely the one need setting)
chop always.
chop if too long.
simple wrap.
The un-tick the wrap long lines all together right on top op the *line wrappingsection, willstop-wrapping`, but you'll need to go through these setting to get it just right - or to get it to format the way you code.
I have a R script file, let's call it "Script.R," that I want to source into R from C# (using R.Net). For example, Script.R has several functions in it that I want to call from C#/R.Net.
For deployment purposes, I have added Script.R as a "Resource" in Visual Studio's "Properties." At run time I can get the text of the Script.R file as a C# String by using the "MyProject.Resources.Script" (where it is assumed that the project is called "MyProject" and the Script.R resource is named with the field "Script.")
Now, I know I can use R's "source" function, as called from R.Net, with the file path of the Script.R, e.g.,
rEngine.Evaluate(String.Format("source('{0}')", filePath));
... but, what I am trying to do (and can't seem to figure out) is how to source (or parse?) the Script.R from the MyProject.Resources.Script C# string. That is, I'd like to source my Script.R from the resource C# string rather than from a file.
Any idea how to do this?
Many thanks in advance!
Okay, so after thinking through how to combine C#/R.Net/R, I found a solution. Here's a broken out solution (using many more variables than need be, but hopefully providing more clarity):
String script = MyProject.Resources.Script;
string[] scriptSplit = script.Split(new string[]{"\r\n"}, StringSplitOptions.RemoveEmptyEntries);
SymbolicExpression rscriptSplitSymbolicExpression = rEngine.CreateCharacterVector(scriptSplit);
rEngine.SetSymbol("rscriptSplitSymbolicExpression", rscriptSplitSymbolicExpression);
rEngine.Evaluate("eval(parse(text=rscriptSplitSymbolicExpression))");
Of course, this can be simplified to:
rEngine.SetSymbol("rscriptSplitSymbolicExpression", rEngine.CreateCharacterVector(MyProject.Resources.Script.Split(new string[]{"\r\n"}, StringSplitOptions.RemoveEmptyEntries));
rEngine.Evaluate("eval(parse(text=rscriptSplitSymbolicExpression))");
If you have a different way of doing it, I'd love to see your solution, too! Thanks!
I've tried for quite a long time to figure out whats going on but I've not found anything anywhere that someone besides me has ran into this issue.
I'm simply trying to hard code a path into a string. Easy stuff. Well for some reason
string fullPathSourceFile = #"c:\SQLSOURCE.txt";
is evaluating to c:\\SQLSOURCE.txt
I've tried everything to evaluated it to a single backslash remove the double quotes and it wont work. I even tried Replace(#"\\", #"\") and it has no affect. Anyone have any idea what's going on with my code that would force a double backslash when a single one should be evaluated? This is driving me nuts and it's so damn easy yet causing me a lot of frustration.
I'm then using the string variable below:
using (StreamReader reader = new StreamReader(fullPathSourceFile))
{
string line;
while ((line = reader.ReadLine()) != null)
{
sqlDBsource = line.ToString();
}
reader.Close();
}
Thanks to everyone for their input which helped my figure out what I was doing wrong. In Visual Studio (which is confusing) when you look at the value of a string in the debugger, it puts escapes in for you, so a double-backslash in a watch window or variable value popup is normal and does not mean there are actually two backslashes. When you mouse-over the variable or watch it in the watch window, click the magnifying glass icon at the right hand side of the tooltip/pane, this will show you the unescaped string at it would be printed to the console. Another way to display the actual results is: Console.WriteLine(the_problem_string); The issue I was having with the code is outside the scope of the post but the confusion of the results I was seeing from Visual Studio lead me to believe the string was the source of the problem when it wasn't.
This was a weird one. So I removed the verbatim as suggested in the comments and it worked when I used the double backslashes in the string. For some reason the code did not like the verbatim string and was translating the backslashes incorrectly. This resolved the issue. If anyone runs in to this you may need to play with the verbatim/non-verbatim strings because in some circumstances the compiler prefers non-verbatim.
My C# code has a lot of statement like "this.Name=...". In order to make my code neat, I let the text editor to replace all "this." to nothing. The code still worked. But later I fund it caused me a lot of new troubles for I wrote some statements like:
this.Name = Name; // the second Name is a parameter.
After the replacement, it became:
Name = Name;
Now, I met too much code. How to find the suspicious code like "Name = Name;" by Regex in VS 2010?
Thanks,
Ying
Why would you want to use Regex when you can simply compile the solution and look for the CS1717 warning:
Assignment made to same variable; did
you mean to assign something else?
Also note that in C# it is a good convention to have your parameters start with lowercase letter.
I would agree that Darin's approach is more robust and should be done first. However you might
have commented out sections of code which will be missed with this approach.
To try and find those you can use "Find in Files". In the Find box tick "Use regular expresssions" and enter {:i}:Wh*=:Wh*\1
:i C Style identifier ("tagged" expression by enclosing in braces)
:Wh* Zero or more white space chars
\1 back reference to tagged identifier found
This approach might bring back some false positives so you could try :Wh+{:i}:Wh*=:Wh*\1:Wh+ if there are too many but at the risk of missing some matches (e.g. where the closing comment mark is immediately after the assignment statement)
You could restore your last commit from your CVS, if you haven't changed too much since.
The problem with doing what you ask is that there might be other cases where "this" shouldn't have been replaced and you haven't seen the problem yet.