We are using enterprise library 4.1 and smart client software factory 2008 to our application.
how we can upgrade enterprise library 5.0 and SCSF 2010 to our application.presently we are using visual studio 2008.
To upgrade what are the thing needs to be taken care.
Early help would be appreciated.
In terms of Enterprise Library, the best case scenario would be to replace the 4.1 assembly references with 5.0 assembly references and change the configuration (to use 5.0 references instead of 4.1 references). However, you could also hit some issues.
You should read the Microsoft Enterprise Library 5.0 Migration Guide for a full description. The Breaking Changes document could also help you determine if you may run in to migration issues.
For the Smart Client Software Factory the approach appears the same: change the references and configuration to use the new dlls. The Web Client Software Factory 2010 Documentation download has a section on Migrating to Visual Studio 2010.
Install the 5.0 package.
remove all the previous refreneces and add the newer ones generated.
You can refer the dlls by copying it to some folders or directly from the location where you have installed (C:\programfiles\Microsoftenterpriselibrary5.0)
I faced the below issues while migrating
Configuration errors in web.config files - some of my references in the web.config files were refering to the older version(2.0.0.0)(i upgraded from 2.0 to 5.0) and the publictokenkey="null"
so i pushed all the dlls to the gac and added the publicktokenkey from the c:\windows\assembly. which solved the issue
And another issue was regarding the microsoft.practices.enterpriselibrary.caching.cryptography- it was displaying soem weird error.- solution-the bin folder was having the old dlls and when tried to
clean the solution the dll reference was still there. SO i deleted all those from the folder and rebuild again.
IT was initially having the logicacmg.enterpriselibraryextensions.logging which caused some issues- i used the microsoft.practices.enterpriselibrary.logging.configuration.rollingflatfiletracelistenerdata which could solve the issue.
Hope some one might get some inputs with this post
Related
I recently reinstalled my Windows 10 OS, and now Nuget packages are "not compatible". After an explanation, I will be asking, how do I resolve this problem.
Lead up
Due to an unrelated problem, I had to reinstall my operating system. In the course of that, I reinstalled Visual Studio 2019. I cloned my repository (https://github.com/PaulSchrum/CogoDN), then opened it locally with VS.
Now when I build, I get several Nuget errors and warnings. These Nuget dependencies have been present in my code since December 2019, and never caused me a problem until this month (July 2020) associated with the reinstallation of VS.
Question: How do I resolve this problem?
Other Details
I am targeting .Net Core 3.1, but it happens no matter which version of .Net Core I target.
The main error seems to be of the pattern:
NU1202 Package System.Drawing.Common 4.5.0 is not compatible with netcoreapp3.1 (.NETCoreApp,Version=v3.1).
This is happening for System.Drawing.Common, netDxf.netstandard, and packages necessary for Microsoft Tests. Specifically, it can't recognize using Microsoft.VisualStudio.TestTools.UnitTesting; (namespace 'VisualStudio' does not exist), and every attribute ([TestClass], [TestMethod]) now is a syntax error.
What have I already tried
Various combinations of reestablishing the Nuget packages. This includes at least twice clearing the Nuget cache and installing the dependencies again. I also followed the advice here: https://stackoverflow.com/a/63108317/1339950 (Item 3) Close VS, Delete global NuGet.config, start VS and let it rebuild Nuget.config.
None of these work.
One last note: I have tried so many things and got into various different states of not working that my description may have inadvertently conflated a few details.
Visual Studio can't resolve Nuget dependencies after reinstalling
operating system
It is quite strange and in my side, I can also build the project without any errors.(I download the project from your github link and then open it with VS0219----build well).
So I think your Net Core SDK or VS IDE have broken.
1), please try to install the latest Net Core 3.1 Developer SDK.
Or you could open Programs and Features from Control Panel, then right-click on every net core sdk-->Change-->Repair
2) run sfc /scannow to scan your os and you can refer to this link for more steps.
3), try to do a repair in VS Installer. Or if your VS2019 is not the latest, please update it to the latest version.
4) try to create a new net core project and then install these nuget packages to check if the issue still persists.
This scenario goes a bit against the whole way nuget works so what i might be asking for is a hack...
My problem:
I need to have Restsharp and Protobuf-net referred to in a .net assembly that going into SQL-CLR for Server 2008 (so max .net 3.5, framework 2.0).
Restsharp goes back to 3.5 as the lowest supported fwk version.
Protobuf-net 3.5 onwards has a lot of gunk referring to system.servicemodel (and WCF) which i don't need and use and actively want to remove because it causes issues with installing on SQL-CLR. Protobuf-net 2.0 doesn't have this :)
So i've built and tested my code with an assembly targeting .net 3.5 and i installed the restsharp nuget - which gave me the correct reference and i manually added a reference to the protobuf-net 2.0 distro.
This is where i'd like to know - can i (in any way) install the protobuf-net nuget package but still have it reference the .net20 DLL in my assembly which targets 3.5?
The static reference is not a huge deal since protobuf-net has been pretty stable, but i'd like to get the whole setup via nuget if possible.
In the end, this is a workaround as solution to:
protobuf-net version without system.servicemodel dependency?
If there's a better answer to that, i'd be very grateful :)
As far as I know, that is not possible. You could of course create your own custom build and host it on a local nuget drop, or as your own nuget package on the public feed. AFAIK, there's no way to do what you want inside a new nuget folder in the existing package.
I was using Visual Studio 2008 with Enterprise Library 4.0. It is working fine and showing namespace Microsoft.Practices.EnterpriseLibrary.Data. Now I installed VS 2010 and Enterprise Library 5.0.(because 4.0 sowsn't support vs 2010 ).
But the problem is Enterprise Library 5.0 doesn't show Microsoft.Practices.EnterpriseLibrary.Data. Is there another namespace in 5.0 thriugh which I can access the Database class which comes under Microsoft.Practices.EnterpriseLibrary.Data namespace?
please let me know.
You are probably targeting .NET Framework Client Profile. The Data Access Block has dependencies on System.Data.Oracle and requires the full .NET Framework.
For anyone else hitting this problem with moving their DAAB-based app to .NET4, entlib5 is supplied with the source code installable via e.g. C:\Program Files (x86)\Microsoft Enterprise Library 5.0\src\Enterprise Library 5.0 - Source Code.msi
Running that msi and accepting the defaults creates a EntLib50Src folder under your Documents area. If you go into EntLib50Src\Blocks\Data and open Data.2010.sln you can change the target framework to .NET Framework 4 Client Profile.
This will create a bunch of errors related to the System.Data.Oracle dependency. Remove the reference to it, and then exclude the Oracle parts of the project and comment out any Oracle references in the common code.
If you then recompile with strong name signing on you can use the output assemblies (Microsoft.Practices.EnterpriseLibrary.Common.dll and Microsoft.Practices.EnterpriseLibrary.Data.dll) with .NET Framework 4 Client Profile. You do have to distribute Microsoft.Practices.Unity.dll from the e.g. C:\Program Files (x86)\Microsoft Enterprise Library 5.0\Bin area but this is client profile-compatible.
Note that the above works if you're not needing Oracle support in your app. Mine doesn't, its SQL Server and VistaDB only. The above should work with any non-Oracle db compatible with ADO.NET.
I have downloaded and installed the Entity Designer Starter Kit on both VS 2010 and 2012. I've created a project and have customized that project to allow me to add (for now) three attributes for each field value: See Below: (I'd post the image but I've only started posting here and I don't have 10 points) :(
As you can't see above, the Extension is working...on VS 2010, however, we need to use VS 2012 - so we can have the new support for geography fields in our Model, but it doesn't seem to work in VS 2012. The extension shows up as an installed extension in the Extension Manager in both versions, but doesn't work (or do anything in 2012.) when we build a new Model or open an existing one. :(
I've looked at the manifest for versioning info, and it DOES show up in the Extension Manager as having been installed (in both versions). (See part of Manifest below -- We are using the Professional version of 2012)
<SupportedProducts>
<VisualStudio Version="11.0">
<Edition>VSTS</Edition>
<Edition>VSTD</Edition>
<Edition>Pro</Edition>
<Edition>Express_All</Edition>
</VisualStudio>
<VisualStudio Version="10.0">
<Edition>VSTS</Edition>
<Edition>VSTD</Edition>
<Edition>Pro</Edition>
<Edition>Express_All</Edition>
</VisualStudio>
</SupportedProducts>
Does anyone have any idea why its not running in 2012?
Thanks for any help!!!!!!!
bob
Back in 2010 I found that the Starter Kit did not work, perhaps due to the version being for VS2010 RC.
So I rebuilt it, and today, I've just upgraded it to VS2012.
So you can get it from my Blog.
All I did was run it though the VS upgrade wizard, and then change the manifest to VS2012 and it worked fine. Perhaps you could explain a little more "geography fields", as I've not read up yet on any of the changes in VS2012.
http://www.jsrsoft.co.uk/blog/post/Entity-Framework-Starter-Kit-alternative
All,
I'm currently in the process of attempting to create a repeatable process for the upgrade of a TFS 2008 installation to new hardware in what Microsoft call a migration upgrade, but am experiencing issues when building the VS 2008 projects on the new hardware.
Our TFS 2008 installation consists of two machines; one which houses the SQL databases and Application Tier, and the other which acts as a dedicated Build Server.
The new hardware for our TFS 2010 installation consists of two machines; one which houses the SQL databases, Application Tier, SharePoint and the Reporting Services.
So far, I have managed to successfully repeat the backup of the necessary TFS databases from the original server to the new server and restore them, followed by the 'tfsconfig import' command to successfully import and upgrade the databases to a Team Project Collection. The Team Project Collection appears correctly, and it is immediately usable. All security settings, shelvesets, workspaces etc. are intact.
Our issues start when we begin trying to build solutions. We are initially trying to build these solutions without upgrading them to the VS 2010 format, nor modifying the target Framework of any of the projects.
We get the following errors when various projects build:
< filename>.resx(x,y): error RG0000: Could not find a type for a name. The type name was 'System.Collections.Generic.List`1[[< class>, < assemnbly>, Version=a.b.c.d, Culture=neutral, PublicKeyToken=9557797252b44220]], mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. Line x, position y. [< projectfilename>]
ResGen : error RG0000: Could not load referenced assembly "< filename>.dll". Caught a FileNotFoundException saying "Could not load file or assembly '< filename>.dll' or one of its dependencies. The system cannot find the file specified.". [< projectfilename>]
Various 'ambiguous' MSBuild target references when compiling workflow-related projects:
C:\Program Files (x86)\MSBuild\Microsoft\Windows Workflow Foundation\v3.5\Workflow.VisualBasic.Targets (153): 'GeneratedCodeAttribute' is ambiguous in the namespace 'System.CodeDom.Compiler'.
There are various suggestions about how to eliminate these issues, including modifying the 32-bit support flag on ResGen, or forcing the use of the 64-bit ResGen, and upgrading projects to VS 2010 format and changing them to target Framework 4.
Issue 1. can be fixed by changing the offending projects to target Framework 4, however this particular project cannot be upgraded yet due to compatibility issues, and I have not yet found a solution for issues 2. & 3.
We have upwards of 20 Team Projects, with multiple branches in each, and would therefore (due to the amount of work involved) like to avoid manually changing all projects/solutions (especially as some products cannot be upgraded to Framework 4 yet for compatibility reasons, and building Framework 3.5 targeted projects in Framework 4 MSBuild does not appear to be as compatible as Microsoft would have us believe).
If anybody has any ideas which may prove helpful, then please let me know.
Cheers,
Antony
EDIT:
Issue 1 has been seen by other people, and relates to resource files referencing generic lists of a custom type. As it turns out, these were superfluous in our project, so I simply removed them, and that build issue was history.
Issue 2 seems to have dissappeared all by itself, possibly as a result of fixing issue 1.
Issue 3 relates to building VS2008 Workflow projects in MSBuild 4, when they target Framework 3.5. Microsoft, in their infinite wisdom, have apparently chosen to not address this issue (Link to Connect site), and there are several ideas to fix it (referencing specific versions of the Framework, changing the build workflow to use MSBuild 3.5), none of which work.
So our upgrade to 2010 is on hold it would seem, until either the products for which we build the 3.5 workflows (CRM 4.0 and SharePoint 2007/2010) support Framework 4, or until Microsoft fix the issue.
EDIT:
Microsoft have admitted that there is an issue, and have released the following information relating to the above KB number: http://support.microsoft.com/kb/2023579
As stated in my commented addition on my original post, this issue relating to the workflows not building is indeed resolved by a patch for the Microsot .Net Framework 4 Extended, which is outlined in KB2023579, which has not yet been made public (at the time of this post).
This solution was provided by Microsoft through a support call, and as such I am bound by the terms and conditions of that call, which prevent me from distributing a link to the patch until the official KB article is made available, at which point I will post the link. Sorry.
Hotfix that worked for us: http://support.microsoft.com/kb/2249629