I just ran into a real headscratcher. I have code that does the following:
var textReader = new StreamReader(path + "\\web.config");
var fileContents = textReader.ReadToEnd();
if (fileContents.IndexOf(oldPwd, StringComparison.Ordinal) == -1)
Log("Old Password Not Found.", 0);
Log("Replacing old password", 1);
fileContents = fileContents.Replace(oldPwd, newPwd);
What I've found is that if the oldPwd contains ^ then things get weird.
1. If the old password ends in a ^, e.g. 123^ then the IndexOf works, but the Replace does will keep the ^ intact. So, with oldPwd = 123^ and newPwd = 456 then Replace will leave the file looking like 456^
2. If the old password has a ^ in the middle of it then IndexOf will return a -1.
I'm baffled to be honest and not sure if it has to do with how I'm reading the file in or what. But I tried this on an online compiler and it worked just fine. So it has to be me, right?
EDIT: I also tried it in my code with hard coded strings and it behaves just fine:
var mystring = "this is a password 123^ yeah";
Console.WriteLine("Did it find it: " + mystring.IndexOf("123^", StringComparison.Ordinal).ToString());
Console.WriteLine("Did it replace it: " + mystring.Replace("123^", "456"));
mystring = "this is a password 123^456 yeah";
Console.WriteLine("Did it find it: " + mystring.IndexOf("123^456", StringComparison.Ordinal).ToString());
Console.WriteLine("Did it replace it: " + mystring.Replace("123^456", "abcdefg"));
FURTHER EDIT: Apparently if I run this through Visual Studio and step through the code it works fine. When I compile the code and run it from the command prompt it exhibits the behavior I outlined above.
The web.config file is just an xml file, so perhaps the way to deal with this is to load the file as an XMLDocument and then simply navigate to the node containing the old password and change its value.
I want to add.. DateTime.TryParse(x) is a good method to see if the date is even going to parse first.. also... it does not account for null data.. so you may need to add a little logic there to handle null.
I'm about halfway through an e-book, hopefully I'll retain enough information to pass the certification test…
I want to quit reading for now and just get my hands dirty in some coding… The examples and exercises are fairly simple and there more for reinforcing what the book was trying to teach…
I thought I would try my hand at creating/coding my own "RSS reader"… That should be fairly simple, shouldn't it?
A web scraper of some sorts should only take about 15 lines of code or less, then parsing that information might even be less than 10 lines of code…
What are the major differences between Windows forms and WPF?
Why choose one over the other?
I just want to create a simple functioning program, it doesn't have to look pretty or anything…
It doesn't have to automatically update or listen to the RSS feed for when it makes changes, that's a feature I can add in later on down the line.
Any kind of feedback towards design practices/patterns would be appreciated.
I'm with Andrew on this.
If you just want to whack something together Winforms is much easier to pick up. I'm a big fan of WPF, and much prefer it for meatier systems, but for a scratch app like this I'd start with Winforms.
Definitely winforms, I still use winforms to whack something together and I've been doing Silverlight for a number of years. If you are learning the language then use the simplest UI you can get hold. Moving to a different UI later will be much easier.
Never underestimate the power of human stupidity
Given your stated aim - to create an RSS reader, this is actually significantly easier in WPF than it is in WinForms due to the deep data binding ability baked inside WPF. There's a straightforward example here[^]. In general, given your level of ability, I would normally recommend WinForms but as this is a well defined and well understood WPF example, I'd say go for it.
You don't do "web scraping" to make an RSS reader. You simply download the RSS feed XML file from the site. Like Pete said, formatting this XML for display is easier in WPF. There are tons of examples all over the web.
I also recommend using WinForms to get started on your coding adventures. However, if you don't need a UI to interact with the user, you could simply write a console app. That would allow you to focus on the problem at hand without having to learn UI programming.
Aside: If you're interested in scraping the web, see this[^] article.
How to make one DLL communicate (tap into data) with another DLL in runtime which will be linked to a different executable.
Both DLLs are being written by me.
The source DLL (one that obtains data) is 99% completed and it is regular .NET C# class library and it gets used by executable A.EXE. Source DLL reads from Socket so once it reads the data, it is gone from Socket, so entry class is implemented using Singleton pattern (private constructor + reference to self + static public accessor)
The new DLL is going to be in C++ (with its public functions all extern "C") and it gets loaded into memory by a legacy application that looks at same data differently.
Both DLLs cannot be kept in same folder and Source DLL cannot be loaded multiple times...
Did Microsoft finally solve the DLL Hell?
Last Visit: 31-Dec-99 19:00 Last Update: 6-Dec-22 0:49