I am currently building a Windows store application using visual studio 2012 in 4.5.1 framework
I have added the reference PresentationCore.dll for the 'bitmapImage' and i am confronted by an error saying 'There has been a mismatch between the processor architecture of the project being build MSIL & processor architecure of presentationCore'
I have tried the method concerning the use of the configuration manager and still seems to not work, would anybody be able to give me any in sight?
PresentationCore.dll is from the Windows Presentation Foundation. You cannot add a WPF DLL to a Windows Store app as you will be mixing between .NETFramework (desktop) and .NETCore (WinRT).
Related
I have a .NRY Standard 2.0 Project with a class library where I use the System.DataODBC (installed as Nuget Package) to connect to an Access mdb file.
I then wrote a .Net Framework 4.7.2 console app to test the library and that works as expected. I then wrote a .Net Core 3.0 console app, because the app that in the end will be using the library is a .Net Core app. But this didn't work I get this error:
ERROR [IM002] [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified
But I then tried to compile the solution with "x86" instead of "Any CPU" - And that works. I then think it must have something to do with the ODBC driver for 32 of 64 bit?
To be clear I haven't configured any ODBC driver with ODBC admin (odbcad32.exe). I can now run the core Console App in Visual Studio and stand-alone.
But when I put the Core Console app on another machine (a clean install Windows 10 pro in a VM) it still won't work.
What do I have to do/install in the VM machine to get it up running?
If you use mdb (the older legacy JET engine), then you can connect on any machine since a copy of the JET database is shipped with each copy of windows. And YES, you will have to force your project to x32 (x86) since the JET data engnie is only available in x32 versions.
If you use ACE, then you are using the newer ACE data engine which is require if you use the Access 2007 and later format (so for accDB files, you MUST use ACE).
Of course like any drivers or software, if you going to deploy to additional machines, then you have to ensure that ACE is installed. As a general rule, you then have to (should) install the access connectivity components. eg this one:
https://www.microsoft.com/en-us/download/details.aspx?id=54920
Keep in mind that there are two versions of the above. A x64 bit version, and a x32 bit version. You want to continue to FORCE you .net project to x32 or x64, since you can't leave this choice to the wind.
So, you have to include the above install as part of your installer, or simply provide a copy, or have users download + install.
The only way to eliminate the need for above is to go with JET, but that may not be a possible choice for you, and you are restricted to mdb files, and can't use accDB files with JET.
Thanks for the quick answer.
But I found that to run a .Net core app using the System.Data.ODBC the app heve to be compiled for x86 CPU and the server where the app is installed needs to have the .Net Core runtime 32-bit version installed.
i develop an Asp core web application (.net framework).
how i specify a run as 32-bit applications?
the publish wizard do not give way to change the Target Runtime, which the selected option is x64 is selected.
I installed on my machine the x86 version of .NET Core Installer.
publish wizard screenshot:
PS Why do I need x86.
I had to run the site on a computer that installed Microsoft Access 32-bit (2003, for an old software).
I also need to access data in Microsoft Access file, which requires me to use the Microsoft.Jet.OLEDB.4.0 driver.
The problem is, probably, that the app's core ASP.NET always running as 64-bit applications, is what gives me the known exception 'driver not registred'
stil after set "enable 32-bit application" in IIS.
i cant install the 64-bit access driver engine, because it requires the removal of MS Access 32-bit...
As mentioned here you need to add the "runtimes" key to your project.json file like below image.
Once you do this, the Target Runtime entry in Publish menu will list all of your specified runtimes. Although this is not enough to get it working since using the Publish menu and selecting x86 version will have no effect and will result in x64 binary files. (This bug may be fixed in future).
The workaround is to navigate to your project folder where the project.json resides. Open a command prompt and type the following to have your binary in desired runtime:
dotnet publish --runtime win7-x86
If you get any error yet, you may need to have the corresponding runtime installed (Download form here).
More info:
https://learn.microsoft.com/en-us/dotnet/articles/core/app-types
https://learn.microsoft.com/en-us/dotnet/articles/core/rid-catalog#what-are-rids
There is also a platform key under buildOptions listing all possible targets, but yet because of some issues (like #1624) it has no effect and it seems the system ignores that.
Built on Windows 10 with VS 2015, our (managed) Windows 8.1 Store app crashes on startup with an odd XAML parsing error on devices running Windows 8.1 (no stack trace or source file given, just caught in the unhandled exception handler, so no chance to debug):
Cannot deserialize XBF metadata property list as 'HorizontalContentAlignment' was not found in type 'null'.
Additional info:
Built on Windows 8.1 with VS 2015, the app will work properly
The app will run correctly on Windows 10 devices
The app is sideloaded on the Windows 8.1 devices
As of the Visual Studio 2015 compatibility guide, the scenario should be supported. Did someone already experience the same issue and overcame it?
I usually trace such cryptic errors to a style or template resource files, and as you indicate I don't find Visual Studio to be as helpful as it should. If you inspect style or template files (e.g., generic.xaml, or your own custom style files, etc), and if some things are missing, Visual Studio usually flags this with a blue wavy underline (I must say not always accurate but about 90% in my guesstimate).
This may turn out to be a non-answer but sharing my experience of XAML parsing errors that leave no clue to go on.
I was very hopeful that since SQL Server 2012 SQLCLR supports .NET 4.0 that SQL Server Reporting Services (SSRS) 2012 would support .NET 4.0 custom code assemblies. When attempting to upload an rdl (via the Report Manager or via RSBuild) that references .NET 4.0 assemblies, the Reports Manager throws an error stating
This assembly is built by a runtime newer than the currently loaded
runtime and cannot be loaded. (rsErrorLoadingCodeModule)
Is there something I can configure to get SSRS 2012 to load .NET 4.0 assemblies? Will we be waiting until the next major release of SQL Server before we see .NET 4.0 support for custom assemblies in SSRS?
SSRS 2014 is now released and custom code still does not support the .Net 4.0 Framework.
See prerequisites in the "Hardware and Software Requirements for Installing SQL Server 2014"
(http://msdn.microsoft.com/en-us/library/ms143506(v=sql.120).aspx)
It's very amusing that SQL Server 2014 has just RTM'ed a few days ago and is already considered a "legacy application" by the .Net Framework guys who say:
.NET Framework 3.5 is not included by default in Windows 8 or Windows
Server 2012, but you can download and deploy it for legacy application
compatibility.
... see "Microsoft .NET Framework 3.5 Deployment Considerations"
(http://technet.microsoft.com/en-us/library/dn482066.aspx)
I think the bigger issue is whether the support lifecycle of .Net 3.5 SP1 can actually be tied to the OS'es for which it was a default component. Whatever they say, I can't see Microsoft quitting support on .Net 3.5 as long as SQL Server continues making it a prerequisite in a product they are releasing today. The .Net Framework guys can't be too happy with the lazy SQL guys right now...
Actually, I find that reports using .Net 4.0 assemblies will work fine in VS 2010 (PreviewProcessingService.exe)...
And the reports may also work for you when deploying them to SSRS 2012 SP1 in SharePoint 2013 integrated mode.
Here is the authoritative answer on when/where the .Net 4.0 CLR is supported by SSRS: http://support.microsoft.com/kb/2869522/en-us
For those of us who use SSRS in standalone mode (without SharePoint), we might be stuck on the .Net 2.0 CLR for a while.
I might be wrong and there might be more differences but having compared reports downloaded from reporting services and "identical" ones made in Visual Studio using .Net framework 4.0+ I think the only difference is that puts a ReportParametersLayout section in the xml. If you manually remove this from the xml version of the report file then upload hopefully it will work for you
My first SQLCLR project is resisting all attempts to deploy...
I get the error
The following error might appear if you deploy a SQL CLR project that
was built for a version of the .NET Framework that is incompatible
with the target instance of SQL Server: "Deploy error SQL01268: CREATE
ASSEMBLY for assembly failed because assembly failed verification". To
resolve this issue, open the properties for the project, and change
the .NET Framework version.
C:...\SqlClr.dll : Deploy error : Could
not create a type for parameter MyModel.Customer customer
The command
select * from sys.dm_clr_properties
returns
directory C:\Windows\Microsoft.NET\Framework64\v2.0.50727\
version v2.0.50727
state CLR is initialized
The Target framework for the project is .NET Framework 2.0
The object referenced in the error message MyModel.Customer is included in the SqlClr project via a Link (Add Existing Item / Add as Link) from another project that is using .NET Framework 4.0, but my understanding is the other project's .NET version should have no bearing.
What might I be missing?
If you are referencing an assembly that is dependent upon .NET 4.0, you're likely in for trouble. My understanding is that SQLCLR assemblies must be based on .NET versions 2.0 through 3.5, because versions 2.x and later prior to 4.0 are really just extensions based on 2.0. That tends to coincide with some information I read recently about an explicit decision for the SQLCLR not to support Framework 4.0.