I have a SSIS project that is deployed on SQL 2012. Since 2012 is EOL, I need to convert to 2019. However, the previous owner used a 3rd party task that does not seem to work in the newer version of VS. When I try to import the project, it sets the default target to 2019. Even if I change that to 2012 and let it convert, it still has errors and restarts VS when I try to open this task (I have installed the task on my machine). And when I create a 2012 targeted project, it allows me to open the task.
The task does not even show in 2019.
I am trying to figure out if it is possible to start a new project. Convert it to target 2012, then then import the existing package.
Every attempt I have made causes it to fail.
I did install VS 2012 and that seemed to work, but then I got a message from our IT group that VS 2012 is to be uninstalled and the project did not seem to open in VS 2017 properly either.
If I do the conversion to 2012, it gives errors, will not allow me to open it, but it does show the task as visible, so I think it is the conversion that is the problem.
I do not even need this to work as is, just need it to know what they have done so it can be converted.
I have the same problem. Both VS2017 and VS2019.
Save the studio when importing target server SQL Server 2012, but there is a version mismatch in the package code that prevents conversion. In particular, the script components.
<Compile Include="ComponentWrapper.cs" />
<Reference Include="Microsoft.SqlServer.TxScript, Version=15.0.0.0, Culture=Neutral, PublicKeyToken=89845dcd8080cc91">
<Private>False</Private>
</Reference>
<Reference Include="Microsoft.SqlServer.PipelineHost, Version=15.0.0.0, Culture=Neutral, PublicKeyToken=89845dcd8080cc91">
<Private>False</Private>
</Reference>
<Reference Include="Microsoft.SqlServer.DTSPipelineWrap, Version=15.0.0.0, Culture=Neutral, PublicKeyToken=89845dcd8080cc91">
<Private>False</Private>
</Reference>
<Reference Include="Microsoft.SqlServer.DTSRuntimeWrap, Version=15.0.0.0, Culture=Neutral, PublicKeyToken=89845dcd8080cc91">
<Private>False</Private>
Must be Version=11.0.0.0
<HostIdentifier>SSIS_SC150</HostIdentifier>
Must be
<HostIdentifier>SSIS_SC110</HostIdentifier>
Related
I'm trying to publish a newly created asp.net 4.6 web project to Azure web apps and receiving the following error:
remote: D:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.CSharp.targets(316,9): error MSB4062: The "Microsoft.CodeAnalysis.BuildTasks.Csc" task could not be loaded from the assembly D:\home\site\repository\packages\Microsoft.Net.Compilers.1.0.0\build..\tools\Microsoft.Build.Tasks.CodeAnalysis.dll. Could not load file or assembly 'Microsoft.Build.Utilities.Core, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. [D:\home\site\repository\WebApp\WebApp.csproj]
Everything builds fine via Visual Studio 2015 on my local machine. I thought Azure web apps were all set to support VS 2015 RTM upon release, but it would appear they do not have MSBuild 14.0 installed. Is there a work around or a roadmap for this problem?
Here was the fix for me.
Using Nuget Package Manager, remove these two packages if referenced:
Microsoft.CodeDom.Providers.DotNetCompilerPlatform
Microsoft.Net.Compilers
After that, run a rebuild. This ensured that the build was not trying to use a specific build exe. Click here for the
Diff against previous revision
In my case I have to edit my .csproj file and find below lines and delete them
<Error Condition="!Exists('..\packages\Microsoft.Net.Compilers.1.0.0\build\Microsoft.Net.Compilers.props')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\Microsoft.Net.Compilers.1.0.0\build\Microsoft.Net.Compilers.props'))" />
<Error Condition="!Exists('..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.0\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.0\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props'))" />
Now everything is fine,
Azure Web Apps doesn't support ASP.NET 4.6 yet. It's on it's way though, so stay tuned.
We are using Azure SDK 1.8 and it working fine on local. we are using TFS hosted build controller to deploy on azure.
It was working fine before but sudden today we getting this error although we have no azure sdk dll version changed but online we get this error. Is this because of TFS build controller upgraded with new sdk? and strange thing this build is showing successful every time.
In TFS build service I found this strange stuff why it is referencing to v2.0 sdk.
Could not load file or assembly 'Microsoft.WindowsAzure.ServiceRuntime, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
If everything else fails, and the correct DLL is deployed in the bin, try adding an assembly binding redirect in the web.config:
<dependentAssembly>
<assemblyIdentity name="Microsoft.WindowsAzure.ServiceRuntime" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="2.0.0.0" newVersion="1.8.0.0" />
</dependentAssembly>
Change the binding version numbers as needed.
This happened to me because I updated the references from 2.0 to 2.2 but I still had the version 2.0 dll referenced in my web config:
<system.diagnostics>
<trace autoflush="true">
<listeners>
<add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" name="AzureDiagnostics">
<filter type="" />
</add>
</listeners>
</trace>
This happened to me when i upgraded to 2.3.0.0.
To fix it i went in to references -> right clicked the dll -> clicked Properties -> set copy local to true.
I believe I've hit the exact same issue as you (if I remember correctly). The 1.8 SDK contained a reference to the old StorageClient dll. Try adding a reference in your project to:
Microsoft.WindowsAzure.StorageClient version 1.7.0.0
Let me know if this helps!
I had this issue as well recently.
Based on my research this can be caused by a multitude of reasons.
The best way to resolve this is to first diagnose it. To get a better diagnosis, enable all CLR exceptions from your Exceptions window. Now your Visual Studio will break on any kind of exception that is thrown. From here you should be able to see the inner details of the exception.
In a Visual Studio 2012 C# console application, I downgrade ".NET Framework Target" from 4.5 to 4.0. Win 7 Pro with both Frameworks installed.
I then reference an assembly, which, through warnings complains the following:
The primary reference "System.Threading.Tasks.Dataflow, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" could not be resolved because it has an indirect dependency on the framework assembly "System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" which could not be resolved in the currently targeted framework. ".NETFramework,Version=v4.0". To resolve this problem, either remove the reference "System.Threading.Tasks.Dataflow, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" or retarget your application to a framework version which contains "System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
If I try to compile at this point, I error, becuase types and namespaces from referenced assembly aren't available, as if the assembly was not referenced at all.
The "Add Reference" dialog doesn't have any System.Runtime choice, but if I manually brose to
C:\Windows\Microsoft.NET\Framework\v4.0.30319\
and reference the System.Runtime assembly found there, warnings go away and I am able to compile.
Questions:
Is such forcing of the System.Runtime version a potential issue down the road (deployment).
If VS Project properties are seto to target Framework 4.0 (doesn't that relate to targeting the 4.0 SystemRuntime/CLR), why isn't the refferenced DLL picking that up and why manually adding the reference to my project fixes that issue?
Even though the library System.Runtime is inside the C:\Windows\Microsoft.NET\Framework\v4.0.30319\ directory, it is not part of the .NET 4.0 framework. .NET 4.5 is an in-place update of 4.0 and is installed in the same folder with the same version number.
Here is a screenshot that proofs that the library does not exist on a play .NET 4.0 installation:
You can also validate this by browsing to the C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework directory where you find the original assemblies for all installed framework versions. You will find the System.Runtime.dll as part of the .NETCore\v4.5 and .NETPortable\v4.5 subdirectories.
The reason that you can add the library to your project is that the runtime did not change between 4.0 and 4.5, so Visual Studio doesn't know or even care that the library you added manually is installed by 4.5. In this case the targetting in Visual Studio is only a filter that avoids that you accidentally add a 4.5 assembly to a project that targets 4.0.
Additional information:
Rick Strahl has a very good blog post on the topic with a more detailed analysis:
http://www.west-wind.com/weblog/posts/2012/Mar/13/NET-45-is-an-inplace-replacement-for-NET-40
Is such forcing of the System.Runtime version a potential issue
Yes, this just won't work. It works on your machine because you have 4.5 installed. Your program will crash and burn on a client machine that only has 4.0. Never add a reference from the Framework directory. It is rather sad that they are still around, they get too many programmers in trouble, but backwards compat is sacred.
The build system can only tell you that you have a problem when you use the reference assemblies. The ones shown in the Add Reference dialog, they are stored in c:\program files\reference assemblies and are not the same as the runtime assemblies. You know that works, you did get the warning. Which, in a somewhat clumsy way, told you that you program won't work on a machine that has 4.0. Don't ignore that warning, you really do have to target 4.5 to use that assembly. Hard requirement you cannot avoid.
why isn't the refferenced DLL picking that up
Because it refuses to build a program that cannot run. Feature, not a bug.
I currently have a VS2012 solution with a WP71 project and a WP8 project. Each of these projects reference a Portable Class Library project where I keep the view models. I also have a Unit Test project that references the PCL and contains tests for the view models.
The problem I'm having is when I compile the unit test project I get the following error:
error CS0012: The type 'System.Windows.Input.ICommand' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Windows, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e, Retargetable=Yes'
All of the projects, including the unit test project, reference the Portable.MvvmLightLibs NuGet package.
After looking around for this assembly I noticed that there are different versions, one for WP8, one for Silverlight 4, etc. Out of all these versions I'm not sure which to use.
The unit test project is targeting .NET Framework 4.5, so I added the System.Windows assembly for that version which works, but I then get the following error:
error : CA0001 : Could not resolve reference to System.Windows, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e, Retargetable=Yes
Seeing as this is a code analysis error I'm tempted to simply ignore this and carry on, but I was wondering if anyone had any ideas on how to solve this or whether it is safe to ignore it?
So, I figured a way to solve the problem.
To get the test project to compile I had to add the System.Windows.dll assembly from:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\Profile\WindowsPhone71
But, adding it using the Add Reference dialog automatically adds the .NET 4.5 version even if I browsed directly to the folder. To fix this I opened the *.csproj for the test project and replaced the line:
<Reference Include="System.Windows"/>
with
<Reference Include="System.Windows">
<HintPath>C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\Profile\WindowsPhone71\System.Windows.dll</HintPath>
</Reference>
This ensured that the 2.0.5.0 version was referenced instead of the .NET 4.5 version. The problem with this approach is certain types conflict with other assemblies, namely the System.dll, but seeing as I'm only testing view models from a Portable Class Library, I'm not all that bothered.
Ideally the test project would also be a Portable Class Library, but I've not got round to testing that.
One other issue was I tend to have warnings show up as errors when building in release mode, so this always fails because there will always be a warning complaining about naming clashes with System.dll.
After installing VS2012 Update 1 I'm unable to create fake assembly for Microsoft.Practices.EnterpriseLibrary.Logging.dll reference. However fakes assemblies for Microsoft.Practices.EnterpriseLibrary.Commom.dll, System.dll and others creates normally. The only solution for this problem I found, was to uninstall Update 1 of VS2012 and things got back to normal. The problem occurred both on local machine and on tfs build server.
Here is the error, that VS2012 shows in its error list:
'Microsoft.Practices.EnterpriseLibrary.Logging.Fakes.StubLogWriter' does not implement inherited abstract member 'Microsoft.Practices.EnterpriseLibrary.Logging.LogWriter.GetFilter(string)' [c:\users\administrator\documents\visual studio 2012\Projects\DeleteMe\DeleteMe\obj\Debug\Fakes\mpell\f.csproj] c:\users\administrator\documents\visual studio 2012\Projects\DeleteMe\DeleteMe\f.cs 68219 DeleteMe 26
I suppose it's a bug of VS2012 Update 1, but maybe I'm missing some property to check or something?
In Visual Studio 2012 Update 1, we removed several internal limitations that caused Fakes silently skip generation of stubs and shims. LogWriter happened to be one of the classes that VS2012 RTM silently skipped. Unfortunately, improvements in Update 1 expose some other limitations in Fakes, which in this case is its inability to distinguish between generic and non-generic overloads of the GetFilter method of the LogWriter class.
As a workaround, remove this type from Fakes configuration. Here is a .Fakes file that accomplishes that.
<Fakes xmlns="http://schemas.microsoft.com/fakes/2011/">
<Assembly Name="Microsoft.Practices.EnterpriseLibrary.Logging" Version="5.0.505.0"/>
<StubGeneration>
<Remove FullName="Microsoft.Practices.EnterpriseLibrary.Logging.LogWriter!"/>
</StubGeneration>
</Fakes>
As a general practice, it is better to modify the default .Fakes files and specify only the stub and shim types you need in your project. This significantly improves build time and helps avoid Fakes limitations that don't apply to your testing needs.
<Fakes xmlns="http://schemas.microsoft.com/fakes/2011/" Diagnostic="true">
<Assembly Name="Microsoft.Practices.EnterpriseLibrary.Logging" Version="5.0.505.0"/>
<StubGeneration>
<Clear/>
<Add FullName="Namespace.TypeName!"/>
</StubGeneration>
<ShimGeneration>
<Clear/>
<Add FullName="Namespace.TypeName!"/>
</ShimGeneration>
</Fakes>