We Keep Coding

Is there a way to modify a Settings.Designer.cs file?

So the thing is at work I was assigned an old project which basically reads data from a table in a database and that data that reads from the first table makes an update to a second table in another database and I was looking a file called Settings.Designer.cs which has auto generated code.
I was looking at the file and has the values which reads the data from (from the first table) and I saw the strings are "hardcoded"
is there a way to make those values dynamics values? Because this file is a internal sealed partial class and I have understood this types of classes can't be accessed

Well, the settings as a general rule are generated from the project settings page:
so, in VS go project and the last option will be "my project name here" properties.
And then you see this:
So things like company name, connection strings, constant values and what not can be created, edited, and maintained from above.
It not clear if you attempted to see/use/look/change settings using above, or there are settings that exist in the desinger file that don't exist in above?
There "might" be a good case - but we assume you at least checked the above first???
I mean, if you add a connection string, or even just some particular constant, or even say some web site company name for the whole site?
When you build the project, those settings get shoved automatic and transferred into web.config for you.
So, at least give the settings page in your project a good look over before you do this. As a general rule, I would not modify that designer file until such time you are BEYOND 100% sure that is your only option. Remember, when you re-build the project, the designer file will get overwritten and re-created. You as a result will "lose" changes and settings as a result.
use the "source means" to work on that project, be it a simple webform, or what not, you want to REALLY try to use the VS built in design surfaces that in turn spit out, crank out those files, and to be honest - not looked at such files for 10+ years, and I never care about these types of generated bits and parts - since I as a developer don't have to create such files. They could be instructions for how to peel a banana for all I care. They are not my concern.
They should quite much be considered temporary files that are transient in nature - and changes to them in general will be lost on next project re-build.

Blazor pages with same variable on different pages causes ambiguous routes (upon rebuild)

EDIT: For some reason, whenever I rebuild the application ALL of my changes to BO.razor are GONE. I created BO.razor by Saving As from BOType.razor, but I try to close BO.razor and reopen it and my changes are kept. The changes are there the first time. Rebuilding and BO.razor gets BOType.razor's content copied to it.
This obviously explains why the routes are conflicting but raises further, more troubling questions.
WTF.
I am trying to build my first Blazor application. The basic idea so far is that you can have different Business Objects with the pages being generated dynamically based on the Business Object Type.
So far I have two pages I'm trying to build
/{BOType}/ - List all valid BOs of this type
/{BOType}/{BOID:int}/ - Display this BO and its related data.
When I first ran the application, it worked exactly as I am imagining. /Form/ shows all saved forms, /Form/1 shows a page with Form 1's data.
When I rebuild the application, or save something while running the application with watch, I get the following exception:
InvalidOperationException: The following routes are ambiguous:
'{BOTName}' in 'BlazorApp.Pages.BOType'
'{BOTName}' in 'BlazorApp.Pages.BO'
Microsoft.AspNetCore.Components.LegacyRouteMatching.LegacyRouteTableFactory.RouteComparison(LegacyRouteEntry x, LegacyRouteEntry y)
InvalidOperationException: Failed to compare two elements in the array.
System.Collections.Generic.ArraySortHelper<T>.Sort(Span<T> keys, Comparison<T> comparer)
The same thing happens if I change the name of the variable (one named BOTName, one named BOType) or if I change the order around (/BOType/ and /view/BOType/BOID, or /BOType/ and /BOType/view/BOID).
The infuriating part is that whenever I try one of these changes it appears to work, because for some reason, the first time it interprets these paths it gets what I mean. Then I change something else and save or just rebuild and I get the ambiguous routes exception.
Does anyone have any ideas on how I can somehow get my original working routes to stick, or some hints to the compiler to interpret it this way? I'm new to web application development so I'm still learning, Blazor's implementation seemed straightforward but apparently is unreliable :(
Thank you

The problem is that Blazor depends on compiler extensions, that the IDE is unaware of (actually it's aware, but imperfectly). Handling razor files mechanically (copying or moving) or rebuilding project may break Blazor's cache.
Sometimes cache is not persistent, so restarting Visual Studio (or whatever IDE are you using) may be enough. In other cases, you have to reset intermediate files as follows:
Quit the IDE.
Open the project directory and delete the output directories (bin and obj).
Reopen and rebuild the project.
If it did not help, and to avoid the same issue in the future:
Never handle razor files like normal files, so no copying and no moving,
If you want to copy a razor page/component, instead create a new one and copy code over. Moving is like copying, but old file gets deleted.
Be careful to give a different name to the copied type.
Renaming is painful. Just do a reset (as described previously) after renaming normally.

How do you set OptionSet Values in Microsoft CRM 2011, based on the text or label?

I am implementing a web service that receives information and needs to map them on the MS Dynamics CRM.
So, when it comes to setting OptionSet values, since I am not the one who implemented the CRM, I have no idea what indices are set up. All I know are the labels. Naturally so do the ones consuming my service. e.g. I call an Opportunity Warm or Cold, not 10033004 and 10033005. But I still need to set this value on the Opportunity entity.
I have found this link - but I think it's really overkill and if that's the only way I can access the OptionSet, then that's just sad.

Couple of options here.
Use the metadata services e.g. Your link, I agree this feels like a bit of an overkill, but you could add caching to reduce the overhead of multiple service calls. If you really don't know what the value is going to be at run time then this is probably the best way.
Just hard code it, if you know at compile time what the values will be then this is probably the quickest option. I've done this before and its usually fine. However this will obviously break if someone changes CRM.
Use the strongly typed classes, this is effectively hard coding just the system does it for you. However you will have regenerate them if CRM changes.
So none of these are a perfect option I'm afraid, but they all get the job done.
Edit
Re: option 3; I mean the early bound entities described here: http://msdn.microsoft.com/en-us/library/gg328210.aspx. I'm not sure how much they will help in this situation. They are strongly types classes which are used instead of the entity class. E.g. contact.firstname instead of entity["firstname"]. I suppose you might be able to use them as a form of metadata - never tried it myself though. Also it has the same problem as option 2, when CRM changes they need to be updated and then compiled.
In this case I'm veering towards option 1 and querying the metadata services, if you do this once and cache the results at the beginning of your process you will always have the most up to date information. This example shows how to get all the metadata in the system http://msdn.microsoft.com/en-us/library/jj603008.

Is this utility useful enough to bother putting into CodePlex?

It was my second C# project, undertaken years ago, and it has lived on, because (imho) it is Genuinely Useful Software. It's also badly designed and the code is embarrassing.
It runs C# code. You write a method, the method name appears in a listbox, you double-click the method name to execute it. That's it.
Examples:
When I open up my C# web project at work, a method runs a couple command-window apps my project needs, and checks to confirm that the requisite service is up. I never have to remember that stuff.
I hate UPPERCASE, so I have a method that lower-cases SQL, but preserves the case of quoted strings. Another method calls a web service to beautify SQL. Those both operate on the clipboard.
One method fixes the names of MP3 files: title casing, replacing underscores and hyphens, optionally removing/inserting text or prepending numbers. Creates a playlist!
I double-click to harvest all of my Twitter links, turning them into an HTML page with hyperlinks and a jQuery-powered search.
A method searches the specified log4net.log for every operation that took longer than the specified number of milliseconds.
I can create a restore point by double-clicking a method (and open up the corresponding dialog with another method).
When my wife had to write some sorting algorithms for school, the utility was an ideal testbed. I use it to test bits of code all the time.
None of these methods is in any way impressive. No large brain stuff. Most of it is just string manipulation, file system operations -- mundane stuff. Handy though!
This morning, I wanted to format some SQL output as rows in an Excel table. I wrote a method to read the output and format it as tab-delimited columns, for import into Excel. I have no idea how else I could have done that. It took about 8 minutes to write.
I have 300 methods, perhaps 50 of which are often useful, the rest there if the occasion arises. Occasionally I move the real cruft into the Zaps group, so it's out of the way.
The utility has lots of ease-of-use features. I prefer the keyboard to the mouse, so methods are tagged into groups that are accessible from a dropdown: control-T selects a different group. Don't remember the group? You enter control-F to find all the methods matching a string. Arrow down and press to run the method. The parameters window always remembers its state: if you entered Hoytster last time, it's there this time. You can right-click a method to see its tooltip; double-right-click to see its source.
I tried to make it easy to create new methods quickly.
A method generates your new function's prototype: you enter the method's name, group tag, tooltip, etc, and the new method is created with the requisite attribute decorations. The prototype is placed in the clipboard so you can paste it into one of the utility's source files.
It's easy to prompt for parameters:
...GetParameters("*Target File", "#Report File", "Open Report [No, Yes]");
opens a window with textboxes labeled Target File and Report File, and an Open Report checkbox with text that toggles Yes and No. Strings in curly-braces become radiobuttons. The Target File must exist, because of the initial asterisk; the parameters window will not close if an invalid target file is entered. The Report File must be valid (it CAN be created) because of the #-sign.
When you run the method and the parameters window appears, it has a [Capture] button you click to generate the code needed to capture the returned parameters, putting it into the clipboard again:
string targetFile = parameters["Target File"];
...
boolean openReport = parameters["Open Report"] == "Yes";
Ach, I go on too long.
So, how ambitious should I be? CodePlex? Maybe a dedicated web site, where people can upload their methods?
Getting the utility publish-ready would be a lot of work. I have to clean up the code; remove the really dumb methods and the never-finished methods; create a screen cast of the "make a new method" process, document the teeny "meta-language" (tongue-in-cheek) that drives the parameters window.
I like the idea of y'all using my utility to be a bit more productive. I love the idea of seeing what methods you invent and share. No doubt it's out there, but I'm not aware of places on the net where people share code as simple as a method "Fix the names of my MP3s".
Would you like to have this utility?
Besides being overworked and lazy, I have never put up a web site (!) -- and y'all might mock me because my GetParameters() method has about 200 lines (my poor excuse: I started out with FORTRAN). This utility was never designed; it accreted. :)
So let me know: Do you think this utility is useful enough to put up on CodePlex (or somplace)?
Thanks in advance! - Hoytster

Put it out on CodePlex and gage the usefulness of it. If it is very useful to many people start moving forward by creating a community around it like the website you talked about. If it is going to be a lot of work and you don't know if it will be useful to people, start small with your effort level and keep moving it up.
I did this exact same thing with my URL Rewriter that I developed, that was based off of Apache mod_rewrite, for the .NET framework.
http://urlrewriter.codeplex.com
I started small and as people requested new feature and started using it more and more, the effort became easy to justify.

Tracking Globalization progress

With our next major release we are looking to globalize our ASP.Net application and I was asked to think of a way to keep track of what code has been already worked on in this effort.
My thought was to use a custom Attribute and place it on all classes that have been "fixed".
What do you think?
Does anyone have a better idea?

Using an attribute to determine which classes have been globalized would then require a tool to process the code and determine which classes have and haven't been "processed", it seems like it's getting a bit complicated.
A more traditional project tracking process would probably be better - and wouldn't "pollute" your code with attributes/other markup that have no functional meaning beyond the end of the globalisation project. How about having a defect raised for each class that requires work, and tracking it that way?

What about just counting or listing the classes and then work class by class? While an attribute may be an interesting idea, I'd regard it as over-engineered. Globalizing does nothing more than, well, going through each class and globalizing the code :)
You want to finish that anyway before the next release. So go ahead and just do it one by one, and there you have your progress. I'd regard a defect raised for each class as too much either.
In my last project, I started full globalization a little late. I just went through the list of code files, from top to bottom. Alphabetically in my case, and folder after folder. So I always only had to remember which file I last worked on. That worked pretty well for me.
Edit: Another thing: In my last project, globalizing mainly involved moving hard-coded strings to resource files, and re-generating all text when the language changes at runtime. But you'll also have to think about things like number formats and the like. Microsoft's FxCop helped me with that, since it marks all number conversions etc. without specifying a culture as violations. FxCop keeps track of this, so when you resolved such a violation and re-ran FxCop, it would report the violation as missing (i.e. solved). That's especially useful for these harder-to-see things.

How about writing a unit test for each page in the app? The unit test would load the page and perform a
foreach (System.Web.UI.Control c in Page.Controls)
{
//Do work here
}
For the work part, load different globalization settings and see if the .Text property (or relevant property for your app) is different.
My assumption would be that no language should come out the same in all but the simplest cases.
Use the set of unit tests that sucessfully complete to track your progress.