We have an ActiveX Control calling Microsoft Point of Sale for .NET. However POS doesn't work with .NET 4.0 due to CAS (Code Access Security) which is obsolete for .NET 4.0.
The best resource I've found is on this LavaBlast Blog, however I've been unable to get it to work.
At what point should I be setting this? I didn't think ActiveX controls had configuration files associated with them for this setting, and wouldn't this be a setting on the user's computer and not on a webserver's web.config file?
Here is the code and the specific error:
PosExplorer explorer = new PosExplorer();
This method explicitly uses CAS policy, which has been obsoleted by
the .NET Framework. In order to enable CAS policy for compatibility
reasons, please use the NetFx40_LegacySecurityPolicy configuration
switch. Please see http://go.microsoft.com/fwlink/?LinkID=155570
Related
We have a legacy web api project developed years ago, it is supposed to be consumed by other internal projects (so not something to be exposed by users over Internet).
The prject was developed in .net 4.6.1 and I am looking at moving it to .net 6. By reading the code and web.config, I got confused with these:
Is it acceptable or best practice to keep on using web.config in .net 6 for these settings or it is better to do in other places? (seems I can't type web.config in stackoverflow and have to make a screenshot)
In our web.config, we have this: <httpCookies httpOnlyCookies="true" requireSSL="true" />
For this web api, we just send some response back and I can't think a place that we use cookie. For authentication, as this web api is consumed by other internal products, we just authenticate the bear token each request sent with the identity server. So is this line really needed? I can't find an equivalent line in .net 6's web.config
There are different ways on specifying application settings in .NET 6, depending on what kind of setting it is and how you want to structure your project. As Marc says the most common application configuration file for .NET Core is that I have seen is: appSettings.json.
You might want to configure some settings directly in your Program.cs and other settings (especially settings that need to be transformed between environments) could be in a transformable settings file like appSettings.json or lauchSettings.json. Read more about configuration in .NET 6 here.
To conclude I would say that it is not best practice to keep the web.config but rather to extract the configuration to the place you see fit. If you don't host you app on a server that needs web.config to run then remove it.
This is a bit harder to answer. If you don't think you need this setting then you can try to omit it when you migrate your application to .NET 6. If you have multiple environments you should test your application (the .NET 6 version) in a non production environment and then you will get your answer if you need to configure that setting or not in the migrated application.
I wish you good luck in your migration journey! :)
I've recently just attempted to deploy a site (it's a web api project) I worked on a Win 2K8 server with IIS installed and the .NET 4.5 framework installed. i was surprised when it didn't work. It basically acted as if it had never heard of the MVC-style routing notion; because it was issuing a controller/action/id type request it didn't know to invoke the routing engine and map this to controller actions.
I eventually took the fairly extreme and silly approach of setting copylocal = true for all assemblies in the project, even the ones that I know must be in the GAC. Bin-deploying it this way works.
So....my question is this - how do I know which need to be copied local and which don't? I mean, I installed the .NET framework 4.5 on the server, and ultimately it seems as if the libraries involved should have been resolved because the .NET framework was installed? Of course the nuget packages all need to be copylocal=true, but within the set of MS standard libraries it seems as if the web site still doesn't find all of them.
Is there a rule I can follow that helps me understand which ones I need to copy locally?
If ASP.NET MVC 4 is the first version you use, and you don't learn every aspects of the framework from a good enough book, I hope you spend some time to review related articles on the Internet to get better understanding,
http://www.hanselman.com/blog/BINDeployingASPNETMVC3WithRazorToAWindowsServerWithoutMVCInstalled.aspx
http://haacked.com/archive/2011/05/25/bin-deploying-asp-net-mvc-3.aspx/
ASP.NET MVC is not bundled in .NET Framework, so most of the binaries you refer to must be set as copylocal=true. This must be painful for beginners, but experienced users are already familiar with that.
We have two server running .NET 4.5.1 and one running .NET 4.0. Before updating the first two, our SSO for forms authentication worked fine. Now, a user will appear authenticated on those first two servers, but not authenticated on the .NET 4.0 box.
All machine keys, decryption keys, cookie domains, etc, are all the same. No code was modified. We simply applied the 4.5.1 update to those two servers.
I've noticed for the 4.0 server, while our authentication cookie IS being passed up, it's not being recognized by the code (I threw a test page on the site and outputted some variables).
Has machine key encryption changed between 4.0 and 4.5.1? Do I need to apply some patch? Thanks.
The encryption APIs have changed in 4.5 see this blog post for more detail - http://blogs.msdn.com/b/webdev/archive/2012/10/23/cryptographic-improvements-in-asp-net-4-5-pt-2.aspx
According to MS simply upgrading to 4.5 wouldn't affect the apps unless the web.configs have changed to target 4.5 which seems odd in your case. You can try adding this attribute to each web.config to force .NET 2.0 compatibility-
<machineKey compatibilityMode="Framework20SP1" />
I have just upgraded my ASP.NET application from .NET 3.5 to 4.0 and have found that the Request.RawURL is set to "/" when requesting the default document, default.aspx, via http://mysite.com/. In .NET 3.5, the Request.RawURL would be set to "/default.aspx".
Is there any way to enable this .NET 3.5 behavior in 4.0?
I have tried disabling extensionless URLs via the registry. I also went through the ASP.NET 4.0 Breaking Changes doc and have set the form tag action attribute, however viewing the source of the page shows that the value set for the action attribute is not being picked up and is reverting back to "/".
Currently running on IIS 7.5 integrated mode and Win7.
Indeed, I can reproduce the behavior when switching between .NET 2.0 and .NET 4.0 -- .NET 2.0 & 3.5 both share the same Common Language Runtime CLR2, with additions to the base class library (BCL) for the higher versions of .NET. With .NET 4.0 came CLR4 and that seems to be where the difference occurs. I never noticed that before!
I believe the new behavior is correct, as RawUrl reflects the URL path that was actually requested. It's difficult to understand your exact need, but I think you might try using Request.Path instead.
URL: http://example.com/
Request.RawUrl: /
Request.Path: /default.aspx
Perhaps you can elaborate a bit more on your application?
Looking for serial port communication using ASP.NET 4.0. I have a cardwriter/reader from IDTECH which talks through a comport. Is there any way to accomplish with .net through the web.
I read things but most of the topics on speaking about .net 2.0 and I was not sure if they created something to handle this in .net 4.0
Thanks
Anything written for .net 2 should work in .net 4 with some changes that occur between revisions. However, using the serial port from asp.net will not work on most servers as the user that the asp.net process is using won't have permission to access the hardware.
The only way around this would be to build the portion of the process that talks with the card reader/writer as a Windows service and add some method of communicating to the service from your asp.net application (TCP connection or something similar).
The only way this is possible is via a browser plugin. This has nothing to do with .NET (unless that's what you use to write your browser plugin).
Everything you see about issues with the .NET serial port control are referring to desktop applications. As a side note, most of the issues have been resolved in .NET 4.0, but not all. I've given up and now use CommStudio, which is available as an ActiveX control, so you may be able to access its methods from a web page.