I have ASP.NET Web Application that is deployed on production already. I had to change the target framework of the project from 4.5.2 to 4.7.2 on my local/source and push the changes to developement to get tested.
The problem I am facing is when I changed the target framework of the project the packages did not 'handle' it very well and I had to uninstall and reinstall them with update-package -reinstall -ignoreDependencies
Everything works as normal afterwards but I will need to commit 99+ changes. I am not sure how to handle this migration between the enviroments. So far all of the changes made in the C# code requred only bulding and exchanging the dll file(copying the one from local to development and replacing it) or direct replacement/add to a new javascript/cshtml file.
How I manage to solve the problem is:
After changing the target framework I had to remap the packages as mentioned above which caused a lot of changed in my source. All I did was to build the new 'version' of the project and get the whole bin folder and replace it with the one of the deplyed project in the server side, also I had to compare the changes in the config files.
Related
In previous versions of what is now .NET Core, using the dnx toolchain, it was possible to run an application straight from source code, without compiling to a DLL on disk. This capability was also present on Azure, allowing you to edit code on the server and have those changes reflected in the live site.
The new dotnet CLI run command seems to automatically create the familiar bin and obj folders with compiled DLLs in them, and the publish process from Visual Studio to Azure now no longer includes the C# source, just the DLL.
Is it no longer possible with the new CLI and other tools to run .NET Core code without creating a DLL on disk?
Short David Fowler response:
Dynamic compilation is gone in RC2. It only exists for views now. There are no plans to bring it back.
Why?
Architectural challenges and changes require to implement it on both .NET Framework and .NET Core. We did it with dnx and there were some problems (like some things being completely broken with in memory assemblies) that we chose to just avoid.
Unfortunately the organization I work for has a legacy .net application made in XP era, we are in the process of updating but that may not take place until a few months or even the end of the year. This .net app is web based and requires .net framework 3.5, it also needs IE9 or less to run, anything beyond this and the app will break and stop working. Somehow the update for framework 4.5.2 installed, I uninstalled it but for some reason it keep reinstalling by itself over night. I uninstall the update and the next morning I will come into work and it will reinstall. I was reading that the app.config could be set for .net apps to set the parameters of what framework they use. I am not sure where the app.config file would be located for this app or how I could find it for a web based .net app?
For an app named Something.exe, the App.config file (if you need one) should be placed in the same folder and named Something.exe.config.
I have an ASP.NET Web API project created on Windows using Visual Studio. How can I set this up for use with DNX/DNVM (on a Mac)?
Switching to Git solved the source control compatibility with TFS. But I wasn't able to find references to getting a project working across both these development environments.
I'm assuming as a first step the project will have to be migrated to ASP.NET 5/vNext but wondering other problems lurk around the corner with different project members using different environments.
I get an error when I run - git:(master):dnx . kestrel
As you mentioned yes you will have to migrate any namespace changes. I have a project that is developed across both. Also changing csproj files to xproj. Support is coming for some kind of interop between the different project types but its not here yet.
For build, publish, deploy from git without relying on VS publish capabilities or MSBuild you can follow my blog post here.
Basically you use DNU to publish and then kudu to deploy.
So here's the thing. I recently updated a web project to use nuget for its dependencies, which in turn updated all of those dependencies to the latest versions.
Quite a task as there were some breaking changes, but I have the thing running locally perfectly.
We use TeamCity to pull the solution from bitbucket and deploy it the the local iis folder on a development (staging) server.
After a build, the website seems very poorly, first off it complains:
Could not load file or assembly
'file:///C:\web\Dev.Pegfect.Presentation\bin\mscorlib.dll' or one of
its dependencies. An attempt was made to load a program with an
incorrect format.
Which is strange since my local copy does not have a copy of mscorlib in its web bin folder. Should be using the GAC? If I remove the dll, I get a new error (some NHibernate issue complaining about reflection). I haven't pursued that since it all seems environmental.
If I copy my local bin folder over the server web bin, it starts to run ok albeit extremely slowly (relative to how it used to).
So, the question "what have you tried" - i am currently installing VS 2012 onto the server and will try building the project from source directly. I am also considering updating TeamCity from v7 to v9.
I could also try to reinstall IIS8.0 on the server.
These are desperate, blind shots in the dark. What would you try?
FWIW the project is targeting .NET 4.5.1 (ANY CPU)
OK, so I will leave it here as it might help someone.
So, the project has been building, deploying and running successfully on the server compiled to .NET 4.5.1 with no problem.
The recent packages update moved us from MVC v4 to MVC v5. (amongst other things). Running .NET fix tool suggested 4.5.1 was corrupted, so I downloaded the developer version and installed and now its fine.
I have downloaded published (code behind files are no there, combined with dll in bin folder) web application from Window Server 2008 where it is hosted, and open it with Visual Studio when I debug that application it shows following error:
"Could not load assembly because this assembly is built by a runtime newer than the currently loaded runtime"
I don't know how can I solve this problem and test application locally.
Please help me.
This errors happens when the DotNet framework you are using is of older version than the one used to build the assembly. You need to check which version of framework is used to build those assemblies and then use the same or higher to debug too.
I was getting this same error when running an installer for a Windows service, even when running the installer on the PC the installer was built on.
It turned out that although the Windows service project had been updated to .NET 4.5, the Setup project that was making the installer was still set to use .NET 2.0.
To check if the Setup project is using an older version of .NET than the project to be installed, in the Visual Studio Solution Explorer:
Expand the Setup project;
Under the Setup project, expand Detected Dependencies;
Under Detected Dependencies select Microsoft .NET Framework and check the Version property. Select the appropriate .NET version from the dropdown list;
Re-build the Setup project to create a new version of the installer.
This error can have a lot of other reasons, too. I had the same problem, and nothing helped until I stumbled across this:
TlbExp.exe error:This assembly is built by a runtime newer
I just ran into this issue when the assembly was built with a target framework of .NET 4, and v4.0.30319 was installed on the server, and other 4.0 apps were running successfully.
The problem arose because the app had originally been built targeting 2.0, and new 4.0 assemblies were pushed, but not the app.config file, which we generally update separately.
This means the supportedRuntime attribute was not updated in the config and caused the error. Adding the following to the app.config fixed our issue:
<startup><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/></startup>
One the the assemblies reference in the project might be built using a newer version of .net, check version of every assembly reference and correct accordingly.
Also check the application pool that this web site is running as. It could be framework 2.0 default on some older windows servers. Change it to framework 4.0.