We've got a Windows 8.1 app that we've converted to a Windows 10 UWP app. The app works fine in debug, but when running in Release (.Net Native), we are getting a runtime error on app load. It's not at all clear what's causing the error. The error happens in the OnLaunched event in App.xaml.cs where some data is being initialized. The error:
An exception of type System.NullReferenceException occurred in
System.Private.CoreLib.dll
Additional information: Arg_NullReferenceException
We're using the latest versions of MVVM Light.
I know this isn't a lot of info, but it's really all we have right now and are pretty stumped. Anyone seen and issue like this or know where to start in tracking it down?
If, you're still using SQLite or any Reference.
Please Right Click to your Project => Add => Reference => Make sure your DLL of Nuget is checked.
Please Check this solution.
I had this exact problem in that I converted an 8.1 app to UWP. This was resolved by including a file called Default.rd.xml in the Properties folder. This was not mentioned in the migration guide that I had used.
Not including it means some pretty common coding patterns such as reflection will not work, and this includes in imported .dll's.
A basic Default.rd.xml file looks like the following ...
<!--
This file contains Runtime Directives used by .NET Native. The defaults here are suitable for most
developers. However, you can modify these parameters to modify the behavior of the .NET Native
optimizer.
Runtime Directives are documented at https://go.microsoft.com/fwlink/?LinkID=391919
To fully enable reflection for App1.MyClass and all of its public/private members
<Type Name="App1.MyClass" Dynamic="Required All"/>
To enable dynamic creation of the specific instantiation of AppClass<T> over System.Int32
<TypeInstantiation Name="App1.AppClass" Arguments="System.Int32" Activate="Required Public" />
Using the Namespace directive to apply reflection policy to all the types in a particular namespace
<Namespace Name="DataClasses.ViewModels" Serialize="All" />
-->
<Directives xmlns="http://schemas.microsoft.com/netfx/2013/01/metadata">
<Application>
<!--
An Assembly element with Name="*Application*" applies to all assemblies in
the application package. The asterisks are not wildcards.
-->
<Assembly Name="*Application*" Dynamic="Required All" />
<!-- Add your application specific runtime directives here. -->
</Application>
</Directives>
If this does not work, then try creating a new empty UWP project to get the latest format for the file.
All,This question may be ignored everyday by us asp.net developer like air. If you think it is dumb, Please don't laugh. Thanks,
We knew the web.config is hosted in every Asp.Net web application. And It's syntax is restricted by the xml and DotNetConfig.xsd. The schema will describe what can be allowed in the web.config.
But When we look in a specified web.config.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
....
</configuration>
We didn't see any place to show this xml is based on the DotNetConfig.xsd.I mean any xml need to be validated should be documented which schema it is from
So that It can be validated in the runtime. Is that right ?
How does the validation works ? Could someone please tell me something about it .
Thanks.
web.config is not strictly validated against the XSD file at runtime. The XSD file is used by Visual Studio as an assistance to developers to avoid typos and other errors in known parts of the configuration file, however because .NET configuration is entirely extensible there is little point in performing XSD-based validation at runtime.
Some validation is performed by System.Configuration classes in the class library when they load configuration data, however per-element validation (in this sense) is the responsibility of the consuming configuration classes rather than the web.config loader/parser itself.
Suppose I have a C# class library project with an app.config file and I reference it an ASP.NET project that has a web.config file. Suppose I have a key in my web.config AppSettings called SmtpServerHostname. If I need the SmtpServerHostname in my referenced class library as well, how should I handle configuring the configuration files? Specifically,
If I don't define the SmtpServerHostname key in my class library, will that "pass through" because it is being referenced by another project where it is defined?
If I do define the key in my class library, which one will take precedence?
I currently make use of web.config transforms when publishing my application. Is it possible to transform the app.config file similarly?
It doesn't work that way. There is no merging. In the ASP.NET application, the app.config settings (or library.dll.config) will not be used in any way. You have to set the web.config yourself for the settings you want the ASP.NET application to see.
This is a duplicate, but I'll answer until I or someone else can properly close it as a duplicate.
I heard from a friend that asp.net relies on/uses a Windows forms class. I tried to figure out which class that might be.
The only class I found was System.Web.UI.WebControls.FontInfo
with the property public string[] Names
that has an Attribute Editor("System.Windows.Forms.Design.StringArrayEditor--snip")
Is there a reference to the Windows.Forms.dll from System.Web.dll?
I think there is a reference from System.Web, Version 2.0.0.0 to System.Windows.Forms.
Check out System.Web.Compilation.ResXBuildProvider.GetResourceReader(Stream) in Reflector.
On line one: ResXResourceReader reader = new ResXResourceReader(inputStream);
ResXResourceReader is from System.Windows.Forms, Version 2.0.0.0
I was curious because I noticed System.Windows.Forms in the loaded modules window in Visual Studio.
ildasm System.web.dll /out =System.Web.il let me quickly search for System.Windows.Forms references. I couldn’t quickly figure out a way to do it from reflector.
There is no reference, and not System.Windows.Forms either.
The StringArrayEditor is a UITypeEditor in the System.Design assembly. This does not get loaded unless used except at design time, when it will be 'lazy-loaded'.
First of all, I am not sure such an existence.
But Namespace or classname doesn't necessary mean you need a reference to Windows.Forms.dll. You can define "System.Windows.Forms.Design.StringArrayEditor" in an assembly outside Windows.Forms.dll.
If you look at the System.Web assembly in the handy Reflector tool, you will see that there is indeed a reference from System.Web to System.Windows.Forms. However, if you use one of the plugins for Reflector that will export the reverse engineered code to files (e.g. FileGenerator), and then search through that, there is no actual use of System.Windows.Forms. Since the .Net runtime will only load assemblies when they are actually needed, the WinForms assembly should never actually be loaded through any usage of System.Web.
Add me to the list of skeptics. But more importantly, it doesn't matter. The way the .Net framework is set up for linking adding or removing a dependance on any of the core assemblies that ship with the framework won't really impact performance in any meaningful way.
In our web applications, we seperate our Data Access Layers out into their own projects.
This creates some problems related to settings.
Because the DAL will eventually need to be consumed from perhaps more than one application, web.config does not seem like a good place to keep the connection strings and some of the other DAL-related settings.
To solve this, on some of our recent projects we introduced a third project just for settings. We put the setting in a system of .Setting files... With a simple wrapper, the ability to have different settings for various enviroments (Dev, QA, Staging, Production, etc) was easy to achieve.
The only problem there is that the settings project (including the .Settings class) compiles into an assembly, so you can't change it without doing a build/deployment, and some of our customers want to be able to configure their projects without Visual Studio.
So, is there a best practice for this? I have that sense that I'm reinventing the wheel.
Some solutions such as storing settings in a fixed directory on the server in, say, our own XML format occurred to us. But again, I would rather avoid having to re-create encryption for sensitive values and so on. And I would rather keep the solution self-contained if possible.
EDIT: The original question did not contain the really penetrating reason that we can't (I think) use web.config ... That puts a few (very good) answers out of context, my bad.
System.Configuration.ConfigurationManager.ConnectionStrings and System.Configuration.ConfigurationManager.AppSettings
Contain settings from the executing application so in your DAL you can get the settings stored in your web.config file.
For your system you can create a custom configuration section that will sit in your web.config file or your DAL's consumer*.config file In these config files you can specify that they load from a separate config file of your design and location.
Referencing external config files from Web.Config
How to: Create Custom Configuration Sections Using ConfigurationSection
Alternativly you can manualy load your DAL configuration data from any file using ConfigurationManager.OpenExeConfiguration
You can add the equivalent to a web.config file called app.config that compiles into a file named for the dll or exe project of your code behind. This is completely changeable without having to recompile. You can use the standard settings for connection strings and various app settings that can be defined in a key/value pair - or with a little more work you can define your own custom config settings class and section. You can even reference settings in your app config - so you could have 3 settings stored in your app (DEV, QA, PROD) and then only reference the one you want at runtime in your app.config file. Here is an example of one that was created for a webs service setting.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<section name="{Project}.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
</sectionGroup>
<section name="microsoft.web.services3" type="Microsoft.Web.Services3.Configuration.WebServicesConfiguration, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</configSections>
<applicationSettings>
<{Project}.Properties.Settings>
<setting name="{SettingName}" serializeAs="String">
<value>{SettingValue}</value>
</setting>
</{Project}.Properties.Settings>
</applicationSettings>
<microsoft.web.services3>
<security>
<securityTokenManager>
<add type="Microsoft.Web.Services3.Security.Tokens.UsernameTokenManager, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" namespace="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" localName="UsernameToken" />
</securityTokenManager>
</security>
</microsoft.web.services3>
</configuration>
It sounds like you do not understand how web.config/app.config work, if I'm reading you correctly. Let's say you have a structure like the following:
DAL Project
References:
Some core libraries
Miscellaneous references
Classes:
DatabaseHelper
ObjectClass1
ObjectClass2
etc...
Web Project
References:
Some core libraries
DAL Project
Miscellaneous references
Pages:
Default.aspx
SomePage1.aspx
etc...
Web.config
In your DatabaseHelper class, you might reference the connection string like so:
string connString = ConfigurationManager
.ConnectionStrings["myConnString"]
.ConnectionString;
When this happens at runtime, your DatabaseHelper class will be running under the same app domain as your web page, and thus, any calls to ConfigurationManager will load the request from the web.config file provided by the web project.
Therefore, you only need the one config file in your web/console/winforms/etc... project, and do not need to worry about having one at design time in each of your class library projects.
If you actually run your DAL as a service or a separate console application or something, then and only then would you need to give the DAL project it's own app.config / web.config file.
Split it up. Use the fixed-XML storage file solution for the database connection, encrypted with .NET's built-in encryptor functions (do not roll your own). Then, using the resultant database connection, look up your 'settings table' in the database. This way you can modify your settings without a redeploy. If your customers need to be able to change the database connection string without visual studio, just write a small Windows Forms app that is capable of generating the encrypted connection string and saving the fixed-XML storage file, and, if necessary, also can connect to DB (via that same file) and modify the Settings table as the user needs.
A completely different approach would be to use SQLite and store all your application settings in there. You can password protect the database in question, if that is of importance to the application, and you can create some simple property/value tables to store the data.
Using the SQLite ADO adapter would only require 1 additional DLL into the projects to access the settings and the SQLite DB itself would be accessible to those folks that don't want to use Visual Studio. There is even a plugin for Firefox to interact with SQLite databases.
You could store the settings in any old Xml file and use the XmlSerializer to take your class and convert it to < - > from Xml. In another answer I wrote some code that did just that. The linked answer serializes a list of simple objects, but it also works to serialize one large configuration object.
Because the XmlSerializer serializes to/from public properties, if you don't want to allow values to change, you might need make the class itself immutable (popsicle style) or have a read-only facade that sits in front of the deserialized one.
It's a handy trick. You can set it up via ConfigurationManager.AppSettings[] with it's own config section and external file references, or you can alternatively just hardcode a specifc xml filename per configuration class.
Take a look of Config.Net - the easiest configuration framework for .NET developers.
A comprehensive easy to use and powerful .NET configuration library, fully covered with unit tests and tested in the wild on thousands of servers and applications.
You could have a Interface that mapped you settings that is used on your DAL. Then on the App you could just use IoC to feed the settings to the DAL.
If you're using a DI framework (like Unity) you can specify constructor arguments. So, hypothetically, your DAL provider could have a constructor that takes its connection string.
I know you can't enforce constructors in interfaces, but that's something we have to deal with. I know the framework has a few places where there are unspoken dependencies on constructor signatures...
Have a look at DslConfig. It seems this solves what you are looking for.