Recently we have noticed that ALTER ASSEMBLY is not updating the dll on the SQL Server. We have been altering the assembly since last two years and never had an issue before. The major change we have done is upgraded the targetted framework on the assembly to 4.8. I don't think this is an issue because we were able to alter another assembly on which we have upgraded the framework to 4.8. We have even decompiled the assembly and validated that our latest code is part of it. When we tracked the ModifiedDate in sys.assemblies, realized that the dll has not been updated. It is still pointing to the old date, while the other dlls got a latest modified date.
No errors or warnings are logged on the SSMS and SQL Server event viewer while running the Alter Assembly. We are not sure why is the assembly not updating. Please help us in resolving this issue.
Thanks
Related
I am using a custom dll with SSRS. After deployment, I may need to update my custom dll with a newer version. Will my reports continue to work?
If the reports do not work with the new version of the dll, how can I get my reports to work with the newer version of the dll?
Short answer is yes, at least in my experience. I've done this successfully in the past - just replace the relevant custom DLL on the server with the updated version. I didn't have to make any changes to the reports using the DLL.
One caveat here - when I was replacing a DLL in situ I would make sure the version number of the DLL was the same; since the report stores the DLL version number this meant as far as the reports were concerned they were still getting the same DLL.
So if you're incrementing version numbers when building your DLL this might not work. As per the comment from #Gil Peretz just test it out in a non-production environment and see what happens.
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1578,5):
warning MSB3247: Found conflicts between different versions of the
same dependent assembly
Foo.Tests -> C:\Foo.Tests\bin\Debug\Foo.Tests.dll
I used this little tool ASMSPY and found out that 3 or 4 of my assemblies all reference mscorlib twice for version 2.0.0.0 and version 4.0.0.0.
I did a full search of all files in my entire solution and found no references to mscorlib. I can't find it in the references folder within visual studio either
This has either cropped up because I've updated the solution from VS2010 to VS2012 or updated the version of ASP.NET to the latest RTM release. I did both at the same time and the warnings has started appearing since.
I've read a few similar questions on SO but haven't found one that's worked for me yet.
Can anyone explain what's happening here and how to fix it?
After allowing Nuget to update ImageResizer 3.1.5 to version 3.2.1 my compiles are failing with multiple errors (all same type):
Error 5 Missing compiler required member 'System.Runtime.CompilerServices.ExtensionAttribute..ctor'
Apparently this is the result of an assembly version mismatch. Deleting all ImageResizer references in the project allows an error-free compile.
Reverting to ImageResizer 3.1.5 also allows a successful compilation.
My project is a simple MVC3 application targeting .NET4 - both ImageResizer 3.1.5 and 3.2.1 are targeting v2.0.50727
Any ideas on how this could be fixed?
Thanks in anticipation!
Update (Jun 20th 2012): The best solution is for the project to roll back extension method support. ImageResizer 3.2.2 will no longer offer extension methods, but some of the functionality will be duplicated in the ResizeSettings and Instructions classes to minimize breakage for those who have already coded against the new alpha APIs.
ImageResizer V4 will most likely require .NET 3.5, and will re-introduce the missing features.
Update: please see this question instead if you have any solutions to this catch-22.
I apologize for the issues.
I'm still trying to gather data and discover a long-term solution, but this is what I have so far:
Workaround A:
In Solution Explorer, expand the References folder in your project, select ImageResizer, and go to Properties. Change the Aliases field from 'global' to 'ir'.
Workaround B:
Set your project to use .NET 2.0, save, then revert it back to using .NET 3.5 or .NET 4.
Workaround C:
Manually remove your System.Core reference and add the correct one back. (The usual culprit is an upgraded project with a System.Core 3.0 reference in a 3.5 project). On ASP.NET, you can do this in web.config.
Workaround D:
Revert to 3.2.0, but only if you're using C#.
Why this is happening
VisualStudio/MSBuild find multiple definitions of System.Runtime.CompilerServices.ExtensionAttribute in the project during compilation, but instead of picking the public copy defined in System.Core, the compiler decides to use the internal, assembly-local copy defined in ImageResizer.dll. Then it complains because other assemblies can't reach it. Inane.
What should happen
Microsoft has used this technique several times in the past without issues, and it's widely documented. The compiler is supposed to pick the public instance for project-wide use, but instead it's picking the 'internal' copy. And this isn't affecting many developers; and only a few can reproduce it with a new project.
Public vs. Internal
V2.3.0 defined ExtensionAttribute as public instead of internal. This caused a compile-timer error in VB projects, but not in C# projects. I immediately released 2.3.1 with it marked internal, but I'm now seeing problems with C# projects instead. Catch-22 here.
It works for other people... and Microsoft! Why me?
http://www.danielmoth.com/Blog/Using-Extension-Methods-In-Fx-20-Projects.aspx
http://www.codethinked.com/using-extension-methods-in-net-20
http://kohari.org/2008/04/04/extension-methods-in-net-20/
Using extension methods in .NET 2.0?
The 'hack' was even featured in MSDN magazine.
How you can help
I need more data to completely figure this out. If you're experiencing the issue, please e-mail a .zip file of the project to support#imageresizing.net, and include your VisualStudio/.NET version numbers (Go to Visual Studio, Help, About, and click Copy Info, then paste it into the e-mail).
Hopefully I'll be able to find the exact circumstance(s) that trigger the problem.
Update - just found this article which implies the only solution is creating multiple versions of the assembly. But Microsoft didn't! What am I missing? Also, NuGet doesn't support 2.0 vs 3.5 versioning, so unless I can find a single-assembly solution I might have to drop 2.0 support.
I have an app that uses both NHibernate and Crystal Reports, NHibernate.dll reference Log4Net 1.2.10.0 (PublicKeyToken=aa95f207798dfdb4)
After upgrading Crystal to ver 13.0.2000 we now have a problem, crystaldecisions.shared.dll now references Log4Net 1.2.10.0 as well, but it seems that the good folk at Crystal Decisions have made the "interesting" decision to recompile 1.2.10.0 leaving the version number the same, but giving it a new public key (692fbea5521e1304) and installed it into the GAC.
So my question is...How to install these log4net assemblies side by side? or trick one of the other assemblies (NHibernate or Crystal) into using the other one.
You should be able to install the standard log4net into the GAC as well. This will allow both versions to be loaded by the assembly loader. Alternately you could recompile NHibernate to use the version crystal does, but you'd have to do that from now on moving forward, so I wouldn't recommend it.
I'm trying to upgrade my WinForms app to the latest versions of NHibernate and Fluent NHibernate, but now I get the SQLite exception "Callback routine requested an abort" on the call to BuildSessionFactory.
I have a working sample project that uses the new versions. I attempted to upgrade my real app by replacing the old NHibernate, FluentNHibernate, and System.Data.SQLite references with the new ones, but that caused the problem.
New versions I'm using:
NHibernate 3.2.0.4000
FluentNHibernate 1.3.0.0
System.Data.SQLite 1.0.76.0
VS 2008 9.0.30729.1 SP
Windows XP SP3 (32 bit)
I eventually traced the problem to having the wrong type of System.Data.SqLite DLL.
Turns out they've added a new version that is not a single DLL deployment - it has dependencies on other DLLs.
This is not clearly explained on the SQLite download page. Also, they use exactly the same names and version numbers, which led to me downloading the wrong one.
Problem went away when I downloaded and referenced the "mixed-mode" assembly.
See my answer to the question New SQLite Mixed Assemblies for more details on how to get the "right" one.