I'm trying to use a generic list as a property of the users profile. I'll admit this is probably just making my life harder than it needs to be but I don't want to change the programming model just because the data store struggles.
I have this in my web.config
</providers>
<properties>
.....
<add name="AListProperty" type="System.Collections.Generic.List`1[[System.Int32]]"/>
<add name="AnotherListProperty" type="System.Collections.Generic.List`1[[MyNamespace.Web.UI.MyReallySimpleClass]]">
</properties>
</profile>
The first property, "AListProperty" works fine. The second one throws a variety of exceptions depending on how I delcare it in the web.config. MyReallySimpleClass is public, serializable and consists of 2 public fields (at present)
So, my questions are
1. Does anyone know where the format for declaring these types in the web.config is documented.
2. What I'm doing wrong? It looks fine, I can't see any semantic difference between the two declarations.
Thanks
It would help if you could also give some details about the exception types and message you are experiencing. Otherwise my guess would be that you may need to qualify MyNamespace.Web.UI.MyReallySimpleClass with the assembly where the type lives, as in MyNamespace.Web.UI.MyReallySimpleClass, MyAssembly. The assembly qualification is not be needed unless the type lives in mscorlib, as System.Int32 does, under App_Code or in one of the assemblies listed in the system.web/compilation/assemblies section of the configuration.
Does anyone know where the format for declaring these types in the
web.config is documented.
See Specifying Fully Qualified Type Names in MSDN.
Try to specify the assembly of YourReallySimpleClass:
...type="System.Collections.Generic.List`1[[MyNamespace.Web.UI.MyReallySimpleClass, MyAssemblyName]]"
Related
I recently ran static code analysis in Visual Studio on a solution and saw a line get flagged for CA2104. Mutable object marked as ReadOnly. I understand why it doesn't make sense to have a mutable type set as ReadOnly, since the properties on the object can change, but I don't understand why this is considered a security problem.
This seems more like a data integrity/code quality problem. The only security related thing that comes to mind is if the user was able to somehow change the properties, they could potentially make the object behave in a different manner, but wouldn't this be true for any mutable object? What am I missing?
Edit: I see that this was marked as a possible duplicate. I read through the linked question, but I do not feel that this answers my question. I understand what the CA2104 warning is saying, however I don't understand why this is categorized as a security issue. This is what I am trying to understand.
Having read the documentation on this. I believe that the warning is raised because although the property is marked read-only. There's nothing preventing the user from changing the properties on the read-only property.
Where user would be the consumer of the assembly/library containing the parent type.
Since the property is read-only it's probably been set because the author doesn't want the property to be changed/re-assigned but there's nothing to prevent any of the properties on the child object from being changed. Which is counter to what read-only means. Hence the warning
I suppose it's a tenuous link to security but still valid if the library author wants to protect the exposed object without allowing it to be modified but that's not what is actually happening.
So as a project matures it will almost certainly be necessary to modify attributes of the resource definitions to cope with additional requirements.
Let's use two trivial examples - to add a country code to a client address, or to remove a middle initial and swap in a middle name field instead.
Currently if the resource definition changes, composer won't read whatever values are extant in the repository. I didn't exhaustively try all combos, but have had to reconstitute my blockchain at least twice because of this problem.
Is there a way to mark fields either as "new" or "deprecated" to get past this that I overlooked? It will be hard to make a case to move a system that can't be changed forward to production.
In the same vein it doesn't seem to like empty or null strings much (at least for participant attributes). Having an "optional" override somewhere would save a lot of extra bounds checking in my application. Is there one of those I missed too?
So you can use the APIs or REST to expose the legacy data? You may be referring to Playground above (its not really a tool for looking at production data, its for model prototyping/sandbox/testing type stuff).
On optional question - can just add that the field is optional in the model - example here -> https://github.com/hyperledger/composer-sample-networks/blob/master/packages/pii-network/models/pii.cto#L20
Is there any strong reasons to choose one over the other when declaring the mappings for url resources?
#RequestMapping(Mappings.USER)
vs
#RequestMapping("${mappings.user}")
I understand that property files can be modified after deployment, and that might be a reason to keep it in properties if you want it to be changed easily, right? But also I think changing them easily could be undesirable. So for those with experience, which do you prefer, and why? I think a constants file might be easier to refactor, like if I wanted to change the name of a resource I would only have to refactor inside the constants class vs if I refactored properties I would have to refactor in the properties file and everywhere that uses the mapping (Im using eclipse and as far as I know it doesnt have property name refactoring like that). Or maybe a third option of neither and declaring them all as literals inside the controllers?
It all depends on your use case. If you need the change URIs without recompilation, property files is the way to go. Otherwise, constants provide type safety and ease of unit testing that SPEL doesn't. If you're not gonna change or reuse them (for example, same URI for GET and POST is very common), I don't see any need for constants at all.
I'm making some changes to an old MFC application. The header "stdafx.h" includes another header "mfcextensions.h" which defines a class "CMemDC". In another header I need to include "afxtoolbar.h" so that I can use the class "CMFCToolBar". The problem is, "afxtoolbar.h" will eventually include "memdc.h" which defines a class "CmemDC". The result is that understandably get compile error 2011.
Now I do have control over our existing code which defines "CMemDC" but this is used in a lot of places so I would rather not change it too much.
What is the best strategy for over coming this? I'm guessing that I could somehow use namespaces, or the other alternative is to rename our existing class "CMemDC" but this is more avoiding the problem rather than solving it for good.
Cheers
Using namespaces is the proper route but you probably also want to look at why CMemDC is declared throughout the whole app. Unless you really need your CMemDC declared everywhere you might be able to get away with removing the include from the stdafx.h and just including in the cpp files that really need it.
C++ namespaces might help you. Put at least one of the CMemDC classes in a suitable namespace, and use their fully qualified names where you want to use each one.
You can avoid using the fully qualified names, and make the namespace usage global in the current scope with
using namespace yournamespacename;
However, this is less explicit (in terms of not being able to directly see which CMemDC are you using at one point in the code) and in case you use both classes in the same scope this won't work.
If you have 2 classes with the same name your best option is to use namespaces. Also you can rename your class as well. But all of that is in your post already. So you have answered question yourself. There is no magic which can help you because you have stuck with the usual problem of the name clashing and namespaces were introduced to resolve this kind of problems.
I'm trying to find out what my choices are when I'm going to use user (persistent) settings.
In vs Studio this is possible in the properties of your project but I'm getting to know the limits there:
Only values are allowed that can be converted to string.
Collections (e.g items in a Listbox, with a name and value) cannot be saved.
What I would like to know, how do you implement user settings with collections, and how do you make user settings?
Emerion
If I understand correctly I think you're probably looking for serialization, and since you mention values that can't be converted to string I assume that you'd probably want binary serialization.
The System.Runtime.Serialization namespace contains classes to help you with this and here's an article that might be useful: Serialization in the .NET Framework