I'm thinking of making a simple self-contained .NET application with WPF that can run on any modern Windows system without requiring the end-user to download and install .NET Framework manually.
As far as I know user just need to click on .exe and wait some time until required libraries are installed.
But applications that were compiled for 3.5 use old L&F on most recent Windows.
Is there any way to make applications look like this:
and not like this (if user already has .NET Framework 4+):
Finally I came up with simple solution. My assumption was wrong and it appears .NET Framework actually uses L&F of currently running version, not the targeting one.
Create App.config (Project -> Add -> New Item... -> App configuration (.config))
Paste following:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup>
<!-- Use 4.0 -->
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1" />
<!-- Use 2.0 - 3.5 -->
<supportedRuntime version="v2.0.50727" />
</startup>
</configuration>
.NET Framework will scan <supportedRuntime> until it finds available. List of supported runtimes can be found here.
Using WIX Toolset 3.11, custom bootstrapper.
Product has minimum requirements of Windows 7 SP1, all the way up to Windows 10. Another wrinkle is that the machine the user may be installing on may not be connected to the internet to download anything.
The end goal is to have .NET 4.6.2 installed prior to executing the installed product. I have a package in my installer that installs .NET 4.6.2 silently. I didn't use the NetFxExtension, because I couldn't figure out how to include the .NET installer for offline installation (all the redist stuff I tried didn't work).
Here comes the problem:
Windows 7 SP1, the default .NET installation is 3.5.
Windows 10, it's 4.something, 3.5 shows as installed in the registry, but not necessarily in the Add or Remove Programs screen.
When I execute the installer on Windows 10, I get my installer UI.
When I execute the installer on Windows 7, I get "Microsoft .NET Framework required for <application> setup". This SEEMS like it's a problem with the BootstrapperCore.config, which is as follows:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<sectionGroup name="wix.bootstrapper" type="Microsoft.Tools.WindowsInstallerXml.Bootstrapper.BootstrapperSectionGroup, BootstrapperCore">
<section name="host" type="Microsoft.Tools.WindowsInstallerXml.Bootstrapper.HostSection, BootstrapperCore" />
</sectionGroup>
</configSections>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" />
<!-- I've tried adding <supportedRuntime version="v2.0.50727" /> here too. Didn't work. -->
</startup>
<wix.bootstrapper>
<host assemblyName="ApplicationBootstrapper">
<supportedFramework version="v2.0.50727" />
<supportedFramework version="v4.0" />
</host>
</wix.bootstrapper>
</configuration>
It does get through the detect phase, which starts prior to the UI being displayed (I start the detect, then start the UI).
I've checked all the "Similar Questions" suggested by Stack Overflow, as well as digging around the various WIX bootstrapper websites.
This is the closest thing I've found, but it's for msbuild bootstrappers, not burn bootstrappers.
I couldn't figure out what is the problem for this exception.
The type initializer for 'System.Data.SqlClient.SqlConnection' threw an exception
First attempt: I was using the WCF Service to make some small application. It works just fine and I can use the LINQ properly. After 2 or 3 days. Maybe after I close Visual studio and load the project again. The exception appear.
The 2nd attempt also the same. I create another project and it work just fine until I do something else (I do not change any code)
SQL Server working fine and I can connect through SQL Management Studio without problem.
A click at Debug error lead me to the connection string from linq file.
What could be the problem? I tried to search but couldn't find the answer to resolve this.
Thank you
This most likely means that there is an error in your app.config file, e.g. badly formed XML or unexpected elements. The error happens because the static fields inside SqlConnection read from app.config to determine trace detail level as described here: http://msdn.microsoft.com/en-us/library/ms254503.aspx
If you have a project that contains the NuGet packages for both Oracle and SQL Server, this solution might help you fix this error.
Uninstall both of these NuGet packages:
Oracle.ManagedDataAccess.Core
System.Data.SqlClient
Open your app.config and check if you still have have any dependent assembly entries listed. If you do, delete those entries now. They might look something like this:
<dependentAssembly>
<assemblyIdentity name="Oracle.ManagedDataAccess" publicKeyToken="89b483f429c47342" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.0.19.1" newVersion="2.0.19.1" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Data.SqlClient" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.5.0.1" newVersion="4.5.0.1" />
</dependentAssembly>
While still in your app.config file, delete the entire Oracle Managed Data Access section if it exists (This might be the only thing that you need to do to fix this problem, however we performed all of the steps listed in this solution). If you have it, it might look something like this:
<oracle.manageddataaccess.client>
<version number="*">
<settings>
<!-- your TNS_ADMIN value would be located here -->
</settings>
<dataSources>
<dataSource alias="SampleDataSource" descriptor="(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=ORCL))) " />
</dataSources>
</version>
</oracle.manageddataaccess.client>
Open the packages.config file and double check to ensure that the entries for the Oracle and SQL Server packages are not still listed - they should be gone, but it doesn't hurt to be 100% sure.
Save your project, and then re-add the NuGet packages.
Delete app.config and then run the program
I also faced that exception once when I reopened my project. In my case the Config file had empty tag and key as you can see below. I removed the appSettings tag to fix the problem.
< ?xml version="1.0" encoding="utf-8" ?>
< configuration>
< appSettings>
< add key="" value="site"/>
< /appSettings>
< configSections>
< /configSections>
< /configuration>
Check if you have the following Windows hotfix installed - KB2840628 - for the .NET FW 4.0 (use Windows Control Panel->Programs+Features and click 'view installed updates') and if so try uninstalling it...
https://connect.microsoft.com/VisualStudio/feedback/details/793500/sqlclr-typeinitializationexception-in-sqlconnection-since-kb2840628
It resolved the problem for me.
In my case , the problem was modifying tag name in app.config file by mistake
just compare your app.config file with another old one .. You will find out the problem
...
I have the same error. And I findout the solution for it by change "app.config":
<configuration>
<configSections>
<sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<section name="O4E.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false"/>
</sectionGroup>
</configSections>
<startup>
<supportedRuntime version="v2.0.50727"/>
</startup>
<applicationSettings>
<O4E.Settings>
<setting name="abc" serializeAs="String">
<value>xyz</value>
</setting>
</O4E.Settings>
</applicationSettings>
<appSettings>
<add key="" value=""/>
<add key="" value=""/>
</appSettings>
</configuration>
Note:
Line [supportedRuntime version="v2.0.50727"] is the most importance.
I've read a lot about this issue, but no one has mentioned the following cause of this error.
Some of our users, who had an older version of VMWare View Client which was then upgraded, are now seeing this issue.
The type initializer for 'System.Data.SqlClient.SqlConnection' threw an exception
Users who only had just the old version of VMWare View Client installed have no problem.
Users who only had just the new version of VMWare View Client installed have no problem.
But users who had an old version of VMWare View Client, but have now been upgraded, do have a problem, and it does continue even if we uninstall VMWare View Client, then install the new version.
We did attempt to reinstall .Net Framework and Visual Studio Tools for Office, but this didn't fix anything.
We haven't found a fix yet, but I hope this helps other users.
Btw, we did check our app.config's and web.config's, and these are all fine (and work perfectly with the rest of our users).
One other discovery:
If your user has local admin rights, this problem doesn't occur after upgrading VMWare View Client.
If they don't have local admin rights, the issue will occur.
So... we're now stuck.
I have a test laptop, and I can reproduce the error everytime when my user ID doesn't have Local Admin rights. If we then grant Local Admin rights, and I log in again, the error goes away.
And I added a load of try..catch's in my code, and found that the exception occurs in this one line of code:
MikesDataContext dc = new MikesDataContext()
So, it's actually making the connection which throws the exception. It does not get as far as the next lines of code which use this connection.
sorry for the late response on this, but after investigating this issue for almost 3 days in a row I thought I'd share my results.
I had the same error pop up in SQL Server Reporting Services, more specifically the web portal after getting HTTP 503 Service Unavailable errors on my browsers.
Turns out that the issue was related to both, the service account that runs the SSRS instance plus the account that connects to the database, which in my case was located on another server than the reporting instance. I haven't yet been able to pinpoint exactly where the problem lies inside the configuration and/or user rights, i.e. where do the accounts exactly need elevated rights. All in all seems that the underlying problem was that the account I was running the web portal code under, didn't have enough rights to call on the System.Data.SQLClient type.
TL;DR: Check your users permissions! Hope this helps someone, I had a long 3 days trying to figure this out.
A similar solution to those mentioned above, but in my case it was the
applicationSettings tag within the app.config that needed to be removed.
I have the same error and the problem was in Web.config.
In my case, just add the connectionStrings tag and its value and problem solved.
<connectionStrings>
your connection strings
</connectionStrings>
I have run across this issue on programs that work fine for months, but sudden stop working.
The fix I have found works every time is to place this as the first call in your Main().
System.Configuration.ConfigurationManager.GetSection("system.xml/xmlReader");
I have a parent application hosted in the root folder of my website. It's a .NET 4.0 application and the application pool is obviously set to 4.0.
I want to configure a child application at:
/blog
This is a .NET 2.0 application (it's BlogEngine.NET). I created a new virtual directory called "blog", pointed it at the appropriate directory, converted it to an application and put it in it's own application pool set to .NET Framework 2.0.
I edited the parent web.config and added:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<location path="." inheritInChildApplications="false">
<configSections>
<section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
</configSections>
....entire web.config basically...
</location>
</configuration>
Right after the element. However, when I go to http://localhost/blog, I get the following error:
The configuration section 'configSections' cannot be read because it is missing a section declaration
Anyone have any ideas what's going on here or what I might be missing?
Unfortunately this is a downfall of the way IIS handles virtual directories. Your parent application's web.config is still read even though it's not in the child application. I tried to nest a 4.0 app as a child of a 3.5 app before and after several days of frustration, SO questions, and forum posts, I finally came to the conclusion that it was more trouble than it was worth.
Why don't you just upgrade BlogEngine to Asp.net 4.0 ?
Download the BE 2.0 Web version open it up in Visual Studio it will ask "Would you like it 4.0?" Say yes then it targets the web.config for you.
You can then just upload the new web.config to your server.
If you have an old BE version then you might want to upgrade it to the last stable release.
I have an assembly with few versions registered in the GAC. Now, I want one of my clients which uses this assembly (version 1.3) to point to the newest version (1.4) without opening the source and recompiling the client.
I saw an article demonstrating a technique for doing so using the application config file (winform application)
here is the config file content :
<?xml version="1.0" encoding="utf-8" ?>
<configuration xmlns:asm="urn:schemas-microsoft-com:asm.v1">
<runtime>
<asm:assemblyBinding>
<!-- one dependentAssembly per unique assembly name -->
<asm:dependentAssembly>
<asm:assemblyIdentity
name="MyFacade"
publicKeyToken="c9c18e16df1654e0" />
<!-- one bindingRedirect per redirection -->
<asm:bindingRedirect oldVersion="1.3.0.0"
newVersion="1.4.0.0" />
</asm:dependentAssembly>
</asm:assemblyBinding>
</runtime>
</configuration>
As you can see, there is a binding redirect from version 1.3.0.0 to 1.4.0.0 for assembly named MyFacade.
Now, there's only a Minor issue with this approach. It doesn't work :)
I'm sure it's something with my code.
Any suggestions?
Thanks,
Adi Barda
first, this is the best source I've found about this subject. There are some differences, for example, they are not using the asm: namespace, and also, you might want to disable the publisher policy by adding <publisherPolicy apply="no" /> as described in the article.
In a previous project we did, we needed even more control, so we needed to catch the AppDomain.AssemblyResolve Event and route to any assembly we wanted. Here you can find more informations about the concept. You'd have to manipulate your app once, though.