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.
Related
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.
I have a list of store information.
Each store has a region, a zone, and a store number.
The way I've been doing this now is:
I have a Store class, and a List with elements type Store.
In each application, I have to add this long list of StoreList.Add(new Store() { ... }), which looks bad, is sloppy, and totally not convenient. So I was looking for a way to use this information across multiple solutions/projects.
I don't want to use a database because I don't really want additional overhead in what could be simple scripts. Is a DLL something I would use in this circumstance?
You said you don't want to use database, but probably its not a bad choice. You can store the information in a XML file and read that on application startup. Having such information in a class and then dll, would complicate things. If you have to modify a store number, you have to deploy that dll on computers running your application, although modification in XML would be required on computers as well but it would be easier IMO.
Also if you have that information in some central database and loads up that information on application start event, it would provide you a much better option of maintaining your application and having lesser changes in client side / deployment.
The problem is not whether you want a database or not, but if you need to store your data once your application closes.
Now, you can use a database (could be an embedded one) or a file (xml most probably).
If all your data is stored in code (not the best option really) then yes, you can move that code to a class library project and distribute it wherever you need it.
But still, at the very least this is what i'd do
Move your list items to an xml file
Create a class that reads this file, and loads it into the list
Add the xml file to your project and mark it as an embedded resource (so it'll be packed with the dll)
You can read the xml file from the assembly directly (check here on SO how to do it)
Hope that helps
I'm working with an MVC 4 app that was originally created with the intention of possibly requiring language localisation so there's a heavy use of .resx files and corresponding embedding of references throughout the project. As it turns out, the app will only ever be used by English speaking audiences and indeed no other languages were ever loaded in. What we've got now is an overhead every time we need to put text on a page and increasing inconsistency as English language is hard-coded into places which can't directly access the resource files such as .js files and reference data in the DB.
Short of a lot of copying and pasting, is there any automated way to extract the English language values from the resource files and replace their references in the views? In a perfect world there'd be a tool to do this and certainly it's conceptually scriptable, does anything like this exist already?
You will have to script it. I have done similar stuff with the O2 Platform AST manipulation Mono.Cecil and mono Cecil APIs.
If you give me a small project with the use can you need (a resx file and an MVC view) I can show you a code snippet example
I haven't seen anything that would take care of this. My first thought is because of the localization issues that could be presented in most "out of the box" solution.
This maybe far fetched, but giving it a shot. Could you write a C# app that would load the assembly that holds the resource file, then loop through every file in the project and replace the resource keys with the values?
As you said, it is possible to be scripted, and this seems like the easiest yet crudest way to complete the task in my mind. Depending on the number of resources you're talking about, obviously it maybe easier and safer to copy/paste.
Satellite assemblies..If you have all app resources placed in a project then create the non-default language you want to implement. For example fr_ca.ErrorMsg | en_gb.ErrorMsg and en_Us.ErrorMsg. The default language can be specified in the main Thread.CultureInfo If en_us then fill you en_us file with all entries need and other resources will only be loaded if it does not exist in the default resource->en_us.
We are localizing our forms and strings in a project and are having a problem; Visual Studio creates a resource file for each form when setting Localizable to true.
It's nothing more than a minor nuisance having to send all of the resource files to translators, but is it possible to get VS to use a global resources file instead?
Thanks!
Like Yoda would say, possible it is.
You will have to dynamically translate the dialogs when they are loaded. I did this on several projects and I would say it's much better than having localized resource files.
As others already said, it is possible to use global resource file manually. I believe that it is actually more problematic and less maintainable but still possible.
Now onto why MS decided on one resource file per form. Well, from Internationalization point of view, this solution is better. On one hand it gives translators one important thing: the context. On the other hand, it is typical for project to grow. It is really unlikely that you will make changes to all forms at once. And you know what? Depending on your deal with translation vendor, you can usually spend less on Localization if just few percent of strings would change. That is just because they can use Translation Memory (TM) software.
With one global resource file, there is usually no context and no way to reasonably use TM. The result is, translations are less accurate and take longer (one needs to actually read large blocks of text to make sure everything is correctly translated).
By the way, you do not need to send out individual resource files. Instead you can use some kind of translation kit generator (or translation manager software) to create something useful for translators (for example translation memory friendly file). Sadly, I cannot give you the names of such tools (although I know that there are few of them) since my employer is using custom system for that and I didn't have a chance to work with other tools.
WinFrom doesn't support generating a global resources for Forms automatically in VS.
You must assign the strings by yourself. For example:
Add a Resources.resx with Resources.designer.cs to your project;
Define your strings in Resources.resx.
In your form.cs code, assign the strings in constructor like:
Label1.Text = Resources.Label1Text;
I am looking at creating a small class generator for a project. I have been reading about CodeDOM so it the semantics of creating the classes does not appear to be an issue, but am unsure oh how to best integrate the generation into the development and deployment process.
How should I trigger the creation of the classes? I have read it should be part of the build process, how should I do this?
Where should the classes be created? I read that the files should not be edited by hand, and never checked into source control. Should I even worry about this and just generate the classes into the same directory as the generator engine?
Take a look at T4 templates (it's built in to VS2008). It allows you to create "template" classes that generate code for you. Oleg Sych is an invaluable resource for this.
Link for Oleg's tutorial on code generation.
The answers to your question depend partly on the purpose of your generated classes.
If the classes are generated as a part of the development, they should be generated as text files and checked into your SCM like any other class.
If your classes are generated dynamically at runtime as a part of the operation of your system, I wouldn't use the CodeDOM at all. I'd use Reflection.
I know of the presence of T4 templates (and know many people use them), but I have not used them myself. Aside from those, you have two main options:
Use a SingleFileGenerator to transform the source right inside the project. Whenever you save the document that you edit, it will automatically regenerate the code file. If you use source control, the generated file will be checked in as part of the project. There are a few limitations with this:
You can only generate one output for each input.
Since you can't control the order in which files are generated, and the files are not generated at build time, your output can only effectively be derived from a single input file.
The single file generator must be installed on the developer's machine if they plan to edit the input file. Since the generated code is in source control, if they don't edit the input then they won't need to regenerate the output.
Since the output is generated only when the input is saved, the output shouldn't depend on any state other than the exact contents of the input file (even the system clock).
Generate code as part of the build. For this, you write an MSBuild targets file. For this, you have full control of input(s) and output(s) so dependencies can be handled. System state can be treated as an input dependency when necessary, but be remember that every build that requires code generation takes longer than a build which uses a previouly generated result. The results (generated source files) are generally placed in the obj directory and added to the list of inputs going to csc (the C# compiler). Limitations of this method:
It's more difficult to write a targets file than a SingleFileGenerator.
The build depends on generating the output, regardless of whether the user will be editing the input.
Since the generated code is not part of the project, it's a little more difficult to view the generated code for things like setting breakpoints.