Point 1):
In one solution called CustomBehaviorsSolution, I have two projects - one is class library and another is silverlight class library project. The silverlight class library project has the class files which are 'linked' to the files of the first project. The solution compiles successfully.
Point 2):
I have another solution which has one silverlight application project and another desktop application project. The silverlight application project has the assembly refernce of the silverlight class library mentioned in Point 1 above. The desktop application project has the assembly reference to the class library mentioned in point 1 above.
Now, when I modify or add any class to the project mentioned in point 1 above and update their references in the projects in the solution 2; I experienced some weird behavior.
The desktop application project gets the new changes from the referred assembly whereas the SILVERLIGHT application project does not get the same changes from the referred assembly.
In ILDASM i saw the referred assemblies of point 1 above and they are alright. The problem is that the silverlight application project is not reading the updations from the assembly reference.
Can someone please help?
(I have been removing and then adding the assembly references.)
I'm using VS 2010 and Silverlight 4.0. (After ensuring almost everything, now I think that it might be a bug in VS 2010 or SL 4.0 ! Possible?
I created the new solution altogether (mentioned in point 2) and then added necessary assembly references and now everything is fine.
It seems that the previous solution was corrupted due to some reason.
Related
Our company has legacy system that heavily relies on T4 and the employee who architected it is gone. It was running fine for us, however recently some developers upgraded to VS2015. The T4 transformations stopped working for them (with error similar as reported below). It looked at though there were references to Microsoft.VisualStudio.TextTemplating.12.0.dll. They changed the references to '14' and all worked for them. However, the same project shared by other developers on VS2013 no longer worked with error:
Compiling transformation: The type
'Microsoft.VisualStudio.TextTemplating.TextTransformation' is defined
in an assembly that is not referenced. You must add a reference to
assembly 'Microsoft.VisualStudio.TextTemplating.14.0,
Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
Are you able to run T4 on same project that is opened in both VS2013 and VS2015? One side note, there was a dependent assembly that the old employee made that all the TextTransformations derived from (it also provides helpers that are used in the *.tt files). Unfortunately it used an interface only present in Microsoft.VisualStudio.TextTemplating.Interfaces.10.0.dll, so that old reference is being dragged aroundÎ. Not sure if that is contributing or not. But basically here is the bottom line:
When all devs on VS2013, everything worked and references were:
Microsoft.VisualStudio.TextTemplating.12.0.dll
Microsoft.VisualStudio.TextTemplating.Interfaces.10.0.dll
Microsoft.VisualStudio.TextTemplating.VSHost.12.0.dll
Then when some went to vs2015, the only way to get it to work was to change out the 12.0* dlls with 14.0, but then vs2013 developers ceased to work.
UPDATE
I might not have clarified our complete setup. We have 20-30 *.tt files in a separate project that is included in the solution with the project that will have Text Transformations applied to it.
We have a helper Extensibility.CodeGeneration.dll (this references Microsoft.VisualStudio.TextTemplating.N.dll files as well) that have several static helpers and also base classes that derive from Microsoft.VisualStudio.TextTemplating.TextTransformation.
The 'templates' project that contains all the *.tt files, every .tt file use static methods from our helper dll. It also references all the same Microsoft.VisualStudio. dlls.
In every *.tt file, we have something that looks like this, where AreaTemplate is a class defined in the *.tt file itself and either derives from Microsoft.VisualStudio.TextTemplating.TextTransformation or one of the exposed base classes in our helper dll.
var template = new AreaTemplate { Settings = settings, Area = area, Layouts = layouts };
Write( template.TransformText() );
It was asked in comments how I obtained/used a 'host'. In searching through code we have a few common scenarios (all done inside the helper dll). In each instance, host is of type ITextTemplatingEngineHost.
Case 1:
var dte = (EnvDTE.DTE)( (IServiceProvider)host ).GetService( typeof( EnvDTE.DTE ) );
Case 2:
var hostServiceProvider = (IServiceProvider)host;
Given #3 above, I think I have to reference the Microsoft.TextTemplating dlls (and not just the Interfaces dll) due to the use/exposing of TextTransformation class.
Also, if I change references to in both my 'Helper' and 'Templates' project to 12.0...in vs2015, I get error about 'you must add reference to 12.0'...I have references to that in both applicable (in my eyes) projects...not sure why VS tells me to add it. I tried adding an explicit reference in the *.tt file using
<## assembly Name="$(ProjectDir)..\..\Assemblies\Microsoft.VisualStudio.TextTemplating.12.0.dll" #>
But then I got the error
The type 'Microsoft.VisualStudio.TextTemplating.TextTransformation'
exists in both
'c:\BTR\Source\Assemblies\Microsoft.VisualStudio.TextTemplating.12.0.dll'
and
'c:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.VisualStudio.TextTemplating.14.0\v4.0_14.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.TextTemplating.14.0.dll'
It is almost like there is a hidden/implicit reference to the latest Texttemplating already built into VS??
Not sure if our setup was a more complicated way to achieve our original goal, but I don't think I'll be able to unwind it and change if we are doing it the incorrect way.
Given our setup let me know if you think I am stuck or not. I was trying to figure out 'conditions' in MSBuild to help support both Visual Studios but couldn't succeed.
Thanks in advance.
Try changing the reference from "Microsoft.VisualStudio.TextTemplating.12.0.dll" to "Microsoft.VisualStudio.TextTemplating.Interfaces.12.0.dll". Each new version of Visual Studio services will have a new implementation assembly that will implement the previous versions interfaces. To maintain backward compatibility, you should only reference the interface assemblies and not the implementation assemblies. You might have to change the templates if they reference anything not in the interface.
Updated
Wow, so you have a pretty complicated setup and I don't know if you will be able to use it in both versions without changing the code like you did.
I think the main problem is in your helper class, in #3 you said that the AreaTemplate class derives from TextTransformation. TextTransformation is in the implementation dll so it will exist in each version of visual studio. If you helper dll is complied to reference it from 2013 and then you use that dll in 2015 it will not work.
When a T4 template is transformed, the text in the file is parsed into a class, that class is loaded into an app domain(separate from the one visual studio is running in) and the class's TransformText method is called. Since your templates reference your helper class, the helper assembly will be loaded into the new app domain, which will in turn try to load TextTemplating 12 in there too, the app domain will not be able to resolve the 12 reference because you are using VS 2015.
In the other direction when you reference text templating 14 from 2015 and try to use it in VS 2013 you will have the same problem, the app domain will not be able to find TextTemplating 14 because you are in VS 2013 and the 14 dll does not exist.
In the last scenario when you are in VS 2015 and your add a link to TextTemplating 12 in your tt files it is failing because the app domain created to run the template has already loaded the TextTemplating 14 dll then you also tell it to load the TextTemplating 12 dll. This goes back to my posts in the comments when I talked about VS backward compatibility, TextTemplating 12 and 14 have the same TextTransformation class in the same namespace and the runtime can't load them both so you get that error.
Few things you can try:
1) Put the TextTemplating 12 dll in the GAC on the VS 2015 machines. In theory, this will let the T4 AppDomain load both copies of TextTemplating and then VS 2015 would be able to use the 14 version while your tt files and helper dll use the 12 version. Leave the VS 2013 machines the same.
2) Do the same as 1 but in reverse, setup the projects to target 2015 and reference the 14 dll then on the vs 2013 machines GAC the 14 dll, not sure if this will work since the 14 dll might have other dependencies on newer vs assemblies.
3) On the vs 2015 machines figure out a way to do binding redirects for the T4 App Domain so that calls looking to TextTemplating 12 would be resolved to TextTemplating 14. Usually binding redirects are done in the app/web.config files but not sure how you would do them for T4, may have to peek at the code and see how the app domain is created and loaded.
I have faced the same problem and I think I have a solution, which works - use the VisualStudioVersion msbuild property to reference the right version of the assemblies. Something like this:
<Reference Include="Microsoft.VisualStudio.TextTemplating.$(VisualStudioVersion)">
<HintPath>..\Dependencies\Microsoft.VisualStudio.TextTemplating.$(VisualStudioVersion).dll</HintPath>
</Reference>
<Reference Include="Microsoft.VisualStudio.TextTemplating.Interfaces.10.0">
<HintPath>..\Dependencies\Microsoft.VisualStudio.TextTemplating.Interfaces.10.0.dll</HintPath>
</Reference>
Make sure the Dependencies folder has both Microsoft.VisualStudio.TextTemplating.12.0.dll and Microsoft.VisualStudio.TextTemplating.14.0.dll.
Seems to work.
We have a very similar scenario to yours, just a bit more complex because our T4 templates depend on a couple of DSL-Tools packages.
I’ve made some tests and in fact the solution for this problem is to remove any reference to Microsoft.VisualStudio.TextTemplating.12.0 and keep the references to the Interfaces assemblies. Exactly as pointed by Frank. This would make the projects and the templates compatible with both Visual Studio 2013 and 2015.
Unfortunately this doesn’t help in our scenario because DSL-tools projects require references to Microsoft.VisualStudio.TextTemplating.12.0 or Microsoft.VisualStudio.TextTemplating.14.0 because the DirectiveProcessor.tt template generates a class that derives from RequiresProvidesDirectiveProcessor, an abstract class that resides in one of those assemblies (depending on the version of Visual Studio you would want to compile the DSL-tools project with).
I suppose that is one of the reasons why DSL-tools projects are upgraded when you open them with higher Visual Studio versions… But that is a pain because it forces large teams like ours to upgrade Visual Studio all at the same time.
recently I have experienced a problem which is really strange. I have a c# VS solution which contains 2 projects: a class library (.dll) and a WindowsForms. I had no issues so far to reference the dll from my WinForms applications. However, now, after I reference it, everything works fine, in terms that while writign code the dll assemblies are recognised, until I try to compile and debug, where the dll is not recognised any more, though it is referenced.
Any help would be apprecited.
Regards,
D.
PS. I have tried both referencing the project and dll...Does that mean that the problem is at the dll?
do you have correct .net target on both sides ?
.net client profile / full .net
Here's a puzzler - something that doesn't work that I assumed would (no surprise there).
We have a library project that is referenced in a few other desktop app projects. The library project is written in VS 2005 (.NET 2.0).
My problem is that some of our apps still live in VS 2005 for the time being (for various reason). I can't seem to reference this library project in VS 2010 without it demanding that I upgrade it to .NET 4, which if I do, then breaks my ability to include it as a reference in my VS 2005 projects.
This type of thing fries my brain. Is there any way I can make this work?
Hmm, that doesn't make a lot of sense. You don't reference a 'library project', you reference the DLL that it produces. Project + Add Reference, Browse tab. There's no known problem with that, within a 95% accuracy guess, mixed mode assemblies have a few hairs.
If you actually try to load a vs2005 project into a vs2010 solution, then yes, it's going to try to convert the project file. And that turns vs2005 catatonic, it doesn't have the time machine to guess what a vs2010 project looks like. Just making a copy of the project directory solves that problem.
Can you change the .NET version back to 3.5 or 2.0 in VS.NET 2010 after it revises the project version to .NET 4.0?
Use a file reference to the built dll, rather than a project reference.
You may also find you need to add an extra bit of compatible-framework info to your manifest file to tell .net to allow your .exe to use .net 4 and .net 2 assemblies alongside each other - if it's not there you'll just get an error on startup. (Sorry, I can't remember the exact details and I'm not at my work machine right now to be able to find them - but if you have problems at runtime, the error message should lead you to the exact solution you need)
Correction: I was thinking of this 'useLegacy' startup setting, which you may need to add to your app.config if you want to use a mixture of .net 2.0 and .net 4.0 assemblies in your application:
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
</startup>
On option, that is a complete PITA, but should work is:
Create a new project file in 2010 that includes everything the 2005 project file has. Just call it MyProject2010.csproj or whatever.
Then, add this project to your 2010 solution.
I have a web solution that contains 5 class libraries and one asp.net web site project. It's an e-commerce solution that is compiled for .NET 3.5 (some class libraries are set to .NET 2).
When I got VS 2010 installed I decided to give a try and upgrading it to .NET 4 but that didn't go so well, can't remember why. I reverted the source code control, cleared all local files, re-downloaded from source control and went back to VS 2008.
I decided to give it another try with VS 2010 due to some issues with VS 2008 but when I build the solution it fails because one of the class libraries is compiling to .NET 4. I checked the project settings and it is set to .NET 2. I have tried doing a clean on the solution, that makes no difference, the project always builds the assembly to .net framework 4.x.
I imagine something is getting cached on the system, i.e. msbuild, etc. Does anyone know where to clear this cache so that whatever is holding my class library hostage to .net 4 can actually let it completely recompile and pick up the project settings again?
Thank you.
This was a problem in the project file having the Tools attribute set which just needed to be cleared for .NET 4 compilation.
I want to learn to use Fluent NHibernate, and I'm working in VS2010 Beta2, compiling against .NET 4, but I'm experiencing some problems.
Summary
My main problem (at the moment) is that the namespace FluentNHibernate isn't available even though I've imported all the .dll assemblies mentioned in this guide.
This is what I've done:
1. I downloaded the Fluent NHibernate source from here, extracted the .zip and opened the solution in VS. A dialog asked me if I wanted to convert the solution to a VS2010 solution, so I did.
2. I then went into each project's properties and configured all of them to compile for .NET 4, and built the entire solution.
3. I copied all the .dll files from /bin/Debug/ in the FluentNHibernate to a new folder on my local hard drive.
4. In my example project, I referenced FluentNHibernate.dll and NHibernate.dll from the new folder.
This is my problem:
If I right-click on FluentNHibernate in the References list and select "View in Object Browser...", it shows up correctly.
Now, when I try to create a mapping class, I can't import FluentNHibernate. This code:
using FluentNHibernate.Mapping;
namespace FluentNHExample.Mappings
{
}
generates an error on the using statement, saying
The type or namespace 'FluentNHibernate' could not be found (are you missing a using directive or an assembly reference?).
The FluentNHibernate assembly is still in the list of References of my project, but if I try to browse the assembly in Object Browser again, it can't be found.
What is causing this?
I also had similar problem.
"Error List" window displayed:
The type or namespace name 'FluentNHibernate' could not be found (are you missing a using directive or an assembly reference?)
But "Output" window was displaying detailed information:
warning MSB3253: The referenced assembly "FluentNHibernate" could not be resolved because it has a dependency on "System.Data.OracleClient, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which is not in the currently targeted framework ".NETFramework,Version=v4.0,Profile=Client". Please remove references to assemblies not in the targeted framework or consider retargeting your project.
In my case; I had created a console application project which was targeting ".Net Framework 4 Client Profile" by default, so changing to ".Net Framework 4" fixed issue for me.
I'm unable to observe this behavior in my build, could it be related to this problem: Weird override problem with Fluent NHibernate and .NET 4
If so you could try http://groups.google.com/group/fluent-nhibernate/browse_thread/thread/ae4013d711d2e4ad as a potential fix.
Isn't there a better way to fix this problem?
I don't want to reference System.Data.OracleClient. So I shouldn't have to target the full .Net framework if I don't even want that reference.
Can't I target the Client Profile of the .Net framework, but add a compiler warning exception somewhere so that it just skips that warning? I know it won't cause a runtime problem because I don't use Oracle.
I get identical problem which says there's also a dependency on System.Web. Same story, this is for a Windows WPF app, so I don't need System.Web. Can't I just target the Client Profile and somehow convince the compiler to keep going?
Thanks,
Hugh
EDIT: I figured this out! I had to compile NHibernate myself though. Opened the 2.1.2 code in Visual Studio and deleted everything that says "Oracle" or "System.Web" and I ended up getting it to build. I do not have to target the full .Net Framework now.
We had this issue and the issue went away if we removed the obj and bin folder from the project which was referencing the NHibernate using project.
So we have 'project1' which uses NHibernate to produce project1.dll.
'project2' references project1.dll.
Problem resolved if we removed the obj/bin folder from project2.
Can't say why, but our solution now compiles fine.
Mike.