I have a C# WPF application. It uses a small commercial framework (https://www.inosoft.com/en/product/product-features/).
I'm building this application both locally and via a buildserver (Azure pipelines). I use a marketplace task to change the assemblyinfo.cs before building: https://marketplace.visualstudio.com/items?itemName=bleddynrichards.Assembly-Info-Task
The build server executes the following tasks:
NuGet restore
Inject/Edit assemblyVersion, AssemblyFileVersion and AssemblyInformationalVersion with the right version info
Build
Now when I run this application, it starts up and runs for a while.
Quickly after starting I hook the VS debugger into the process.
Then all of the sudden the application crashes:
This is weird, because when I build locally, this runtime error does not occur.
Note that i set all properties to the same values for testing:
AssemblyVersion: 1.2.3.4
AssemblyFileVersion: 5.6.7.8
AssemblyInformationalVersion: 9.10.11.12
I then use Telerik justAssembly to compare the build output from my local build and the buildserver:
As we can see the local output (on the left) does not have a version added to the Application.LoadComponent(..) whilst the build server output (on the right) does.
public void InitializeComponent()
{
if (!this._contentLoaded)
{
this._contentLoaded = true;
Application.LoadComponent(this, new Uri("/HmiMetis;component/views/app.xaml", UriKind.Relative));
}
}
This means that this is the root cause of the runtime exception.
I find it weird that the build process on my local machine differs from the build server output. Both (should) use visual studio 2017 to build. Why does the buildserver add the version to the uri of loadComponent and my local machine does not?
Anyways, I need this exception gone.
Therefore I think the easiest way would be to force the buildserver to not add the version information under any circumstances. Is this possible and how?
Edit:
I Found a relating issue report that may have something to do with this:
https://github.com/dotnet/core/issues/3189
I've installed a new instance of visual studio 2010 premium and everything seems to work fine when I load old projects. When I start to write new classes though, the var keyword is not working or showing up in intellisense. This is a new solution and no web project. (so no web.config) Target framework for the project is set to .net 4.0. When I try compiling it by writing
var x = "this";
I get "A get or set accessor expected" error.
Do I need to reinstall? Any ideas what could be wrong here?
You don't have parentheses after your method name so the compiler thinks you're defining a property.
public void Server_Test()
{
var ...
}
I used IBM.Data.DB2 version=9.7.4.4 and everything worked perfectly.
But I couldn't use a performance profiler and the support told me I should try
with new IBM version = 10.1. I installed it and had problems at first. I had to register a reference to it in GAC, etc.
Now to my question: If I browse to C:\Program Files\IBM\SQLLIB\BIN\netf40_32\IBM.Data.DB2.dll
and look properties I have version: 10.1.0.4 but when I add reference in visual studio
I have version = 9.7.4.4 in the property window and I am not sure if the right version is used.
How do I get
the right version into property window in visual studio?
I solved this problem by using the IBM.Data.DB2.dll from C:\Program Files\IBM\SQLLIB\BIN\netf40_32\specific\IBM.Data.DB2.10.1.0.dll.
So I got the right version, then I had SQL1159 initialization error with db2 .net data provider reason code 2. The db2app.dll was searched in wrong directory (File not found: http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.messages.sql.doc/doc/msql01159n.html)
I reinstalled the db2 client and now it works...
I downloaded the latest MonoTouch (4.0.4.1 and MonoDevelop 2.6 beta) to fix some issues we were having.
I was hoping that my build in Jenkins (using mdtool) would start working, but no luck.
mdtool gives this error (shortened):
2011-07-28 08:18:47.399 mdtool[14484:60f] *** __NSAutoreleaseNoPool(): Object 0x492260 of class NSCFString autoreleased with no pool in place - just leaking
2011-07-28 08:18:47.401 mdtool[14484:60f] +[NSDictionary dictionaryWithContentsOfFile:]: unrecognized selector sent to class 0xa0bdd3ec
2011-07-28 08:18:47.401 mdtool[14484:60f] *** __NSAutoreleaseNoPool(): Object 0x3f02540 of class NSCFString autoreleased with no pool in place - just leaking
In the past this was related to code generation with the designer.
Is this a known issue being working on by Xamarin? (I can open a bugzilla bug if needed)
PS: one thing else to mention, is we have deleted the designer.cs files for several of our views. (This was a crude way to disable code generation at the time, we needed to manually setup our outlets, exports, etc.)
EDIT: posted to bugzilla here.
You are not using the stable version of MonoDevelop, you are using an outdated preview, that was fixed in later betas.
I'm working on a utility for SharePoint. It's an app that works for both SharePoint 2007 and 2010. When I have a reference to the 12.0.0.0 version of the SharePoint.dll, the app works for SharePoint 2007, but not for 2010. If I reference version 14.0.0.0 of the dll, then the app works great for 2010, but not for 2007.
I can easily tell which .dll that I need to use by looking on the file system with the following code, checking for 12 in the path (SharePoint 2007) or 14 (SharePoint 2010).
System.IO.File.Exists(
Environment.GetFolderPath(Environment.SpecialFolder.CommonProgramFiles) +
#"\Microsoft Shared\web server extensions\14\ISAPI\Microsoft.SharePoint.dll"));
When developing, I make the reference in Visual Studio, so it builds either for 2007 or 2010. I want to be able to release the app where it works on BOTH version of SharePoint. So, I need some way to load/use whatever .dll makes sense for the user running the app.
How do I dynamically choose and load a .dll at runtime?
Reflection? Dependency Injection? You are making life hard for yourself!
Compile against Microsoft.SharePoint.dll v12 and it will work on 2007.
Deploy to 2010 and it will 'just work' (in nearly all cases) as SharePoint 2010 already has binding redirects setup so any reference to v12 will be redirected to v14.
You don't need to do anything configuration wise.
The only situations where you need to get more complex than this are
Instances where something would work
on 2007 but not on 2010 (I can't
think of anything to hand).
Where you may want to make use of 2010 specific features.
If this is the case then what I, personally, would do is to dual compile. Modify the .csproj file to produce 2 slightly different versions, use a parameter and conditional compilation (just like you would with #if DEBUG) for product specific versions of code where necessary (there will be very few of these). You can also use these conditions in the references in .csproj e.g.
<Reference Include="Microsoft.SharePoint">
<HintPath Condition="'$(SP2010)'!='true'">PathToV12\Microsoft.SharePoint.dll</HintPath>
<HintPath Condition="'$(SP2010)'=='true'">PathToV14\Microsoft.SharePoint.dll</HintPath>
</Reference>
Disadvantages
You end up with 2 versions of your
program
Advantages
You end up with 2 versions of your program! Many of the changes you might want to make in the 2010 version would be in manifet.xml, feature.xml and the other config files - reflection, dependancy injection etc isn't going to do anything for you here.
Still have a single version of source code (with minor conditional compilation)
Compiler will pick up more errors (it can't for example figure out at compile time that that funky thing you are doing with Reflection to call a new method in v14 will actually work)
You need to use reflection. Have a look at Assembly.LoadFile and Assembly.Load.
If you need to work with class methods in it you can use it like this :
Assembly u = Assembly.LoadFile(path);
Type t = u.GetType(class title);
if (t != null)
{
MethodInfo m = t.GetMethod(method);
if (m != null)
{
if (parameters.Length >= 1)
{
object[] myparam = new object[1];
myparam[0] = ......;
return (string)m.Invoke(null, myparam);
}
else
{
return (string)m.Invoke(null, null);
}
}
}
else
{
// throw exception. type not found
}
By way of AppDomain.AssemblyResolve, you can check for the existence of the DLL and return whichever one is present:
AppDomain.AssemblyResolve += delegate(object sender, ResolveEventArgs e)
{
if (e.Name == "Microsoft.SharePoint")
{
// do your check here and return the appropriate Assembly
// or maybe just skip an explicit check and instead return either
// Assembly.Load("Microsoft.SharePoint, Version=14.0.0.0") or
// Assembly.Load("Microsoft.SharePoint, Version=12.0.0.0"), whichever works first
// but beware of recursion!
}
};
An assembly binding redirect won't work for you in this case because that is static in your config file and you want this to dynamically work on any machine with either SP2007 or SP2010.
I think you need to look at assembly binding redirection in the framework.
http://msdn.microsoft.com/en-us/library/2fc472t2.aspx
You can use the '.net framework configuration tool' to configure the redirection.
This sounds like a great case for Dependency Injection using one of the DI frameworks like Unity or Castle Windsor. There are others out there, but I'm already risking a religious war simply by mentioning these two. :)