I want to run a background task that will use a lot of the same code as the main project, so i have created a new project for my background task, and a new shared project for my shared code.
I have transferred all of my shared code to the shared code project, i have added the reference to my shared project into my main project and the project works.
I have then added a reference to my shared project into my background task project, built the solution and it works (works as in compiles).
As soon as i add the reference to my background task project into my main project, when i try to build the solution i get the following error:
A public type has a namespace ('BackgroundTask') that shares no common prefix with other namespaces ('SharedCode.Functions'). All types within a Windows Metadata file must exist in a sub namespace of the namespace that is implied by the file name. BackgroundTask C:\Users\User\documents\visual studio 2015\Projects\Project\BackgroundTask\WINMDEXP
If i dont add the reference to the background project within the main project and i try to run the background task, it fails.
In my background task project, at the top, i have included using SharedCode;
And when the task runs, it just needs to make one call to the shared code:
await SharedCode.Check();
The background task project, doesnt need to use SharedCode.Functions directly, that would be called from within the SharedCode project itself.
Any ideas?
And just for reference, the shared code will make a http request and update a local database using SQLite.net-PCL
It seems there is a base namespace rule for shared projects and Runtime Components. (I've never heard of this before.)
Because of the way code generated form a runtime component is exported it must have a single root namespace. The easiest way to achieve this is to use project names with a common prefix before a dot.
So instead of having projects called
MyApp
SharedCode
BackgroundTask
You call them (and set the root namespaces)
MyApp (or MyApp.Client)
MyApp.Shared
MyApp.BackgroundTask
As an alternative you may make things much simpler for yourself if you might instead be able to use an in-process background task (depending on what your task does.)
It seems that you are using an old 'shared' project template that was used on Windows 8 / Windows Phone 8.
In this kind of projects, the code is actually duplicated into the different parent projects meaning that even if you see three projects here, only two exe/dll will be generated. The code in the shared project will be copied into the windows and into the windows phone project.
To achieve what you are trying to do, you can simply create a regular class library (Universal Windows) to host your shared code, a Windows Runtime Component (Universal Windows) library to host the background task entry point and a Blank App (Universal Windows).
Both your background task and your app will reference the shared class library.
You can also leave all your shared code in the background task library (WinMD) and consume it from your application.
Related
I'm new to programming so I might not be using some of the correct terminology. I'm running into an issue with InteliSense when calling a C# class from another project within the same solution. It's not suggesting a using statement and is instead trying to get me to create a new class inside of the current project which is not what I want. I am having to go in and add a refernce to the project and then add the using statement in order to get access to the class.
I looked at some of the documentation online and nothing has helped so far. InteliSense appears to configured correctly to suggest using statements. It provide suggestions just fine. I've been able to create lists and then use it to add the proper using statement along with some other things. Just doesn't want to work with anything inside the solution. I've been following a couple of different tutorials including, .net core 2.1 and 3.1, inside MVC and Razor page projects along with a couple just straight C# console apps. It doesn't work in any of them when I start adding multiple projects to the solution and try using classes from outside the current project.
I am having to go in and add a refernce to the project and then add the using statement in order to get access to the class.
That is the correct behavior. In order for ProjectB to use classes defined in ProjectA, you must first add a reference to ProjectA. Just having the projects in the same solution is not sufficient.
The purpose of having multiple projects in the same solution is simply for grouping related code. The projects may or may not actually depend on each other. For example, a web application may have a separate projects for the actual web UI (the pages themselves), a data access layer, unit tests, maybe some class libraries for shared code used by multiple projects, and maybe even console applications (or some other project type) for performing backend administrative tasks. In this scenario, the web UI and console applications may have references to the data access layer project and/or the class libraries. The unit test project will have a reference to the web UI project, and so on. The dependencies are one-way - you may not have circular references (the unit test project has the web UI project as a dependency, but not the other way).
I've added a ScheduledTaskAgent project affiliated with my WP8 project - I added a reference in the WP8 project to the ScheduledTaskAgent project. In the ScheduledTaskAgent project's OnInvoke() code, I want to query a WAMS table that is already defined in the WP8 project. The WAMS code is "greek" to the ScheduledTaskAgent project. IOW, this is not recognized by it:
protected override void OnInvoke(ScheduledTask task)
{
IMobileServiceTable<WAMS_INVITATIONS> table =
app.MobileService.GetTable<WAMS_INVITATIONS>();
MobileServiceTableQuery<String> query = <bla>;
return await query.ToListAsync();
. . .
}
...which is not at all surprising, because "app" is the other project's App.xaml.cs class, and WAMS_INVITATIONS is the class in the other project that defines the table to be queried. So...is it okay for a ScheduledTaskAgent project to add a reference back to the foreground project that references it, or will this circular reference cause problems? Otherwise, I need to copy over the MobileService declaration from App.xaml.cs and the table definition class from the foreground project?
I made IMobileServiceTable understandable to the compiler by adding a reference to "Windows Azure Mobile Services Managed Client" to the ScheduledTaskAgent project.
kindasimple's answer is correct, however once you successfully get your agent building, it's likely you will hit a known issue: the current Mobile Services SDK cannot be used in background tasks on Windows Phone. The SDK makes references to UI components and your app may not pass certification due to that. We are aware of the problem and working on a fix, just wanted to give you a heads up.
I'm writing applications and libraries simultaneously, and whenever I update a library it's a bit hard to get it recognized in the consumer application. I have open a separate Visual Studio instance for each library and application. After rebuilding a library I get in the consumer applications the warning/error below. I then either have to remove the reference and add it again. Or I have to clean and build the library solution 3-4 times, for such warning/error to disappear in the consumer app VS solution. Why would doing that 4 times make any difference to doing it 1 or 2 times..?
Would like to understand why this happens and if something can be done to make this work more smoothly?
Not sure if it's relevant but most of my applications I write in VB.NET and libaries in C# (as I'm in progress of changing everything to C#). I also have C# files from the libraries open in the consumer application VS, as it pops up during debugging. I also reference library dlls in the library project /bin/Debug folder, because I'm making a lot of changes at this point of development.
Warning 1 Namespace or type specified in the Imports 'somelibrary'
doesn't contain any public member or cannot be found. Make sure the
namespace or the type is defined and contains at least one public
member. Make sure the imported element name doesn't use any
aliases. 'local path'
..
Error 72 Unable to load referenced library 'path\somelibrary.dll': The
process cannot access the file because it is being used by another
process.
I'm writing applications and libraries simultaneously, and whenever I update a library it's a bit hard to get it recognized in the consumer application. I have open a separate Visual Studio instances for each library and application.
This is the fundamental source of your problem. Visual Studio does not like it when things outside it's control change. You should have a single solution open with all the relevant projects included in it. Then when something changes, all the projects which depend on that project will automatically be rebuilt. (At least, that's the default.)
After rebuilding a library I get in the consumer applications the warning/error below. I then either have to remove the reference and add it again. Or I have to clean and build the library solution 3-4 times, for such warning/error to disappear in the consumer app VS solution. Why would doing that 4 times make any difference to doing it 1 or 2 times..?
I don't think it has anything to do with how many times you clean and rebuild it, but how long it's been since you last made a change - you have to wait long enough for the VS instance building the dll to release the lock on the file, before the VS instance that is using it is able to access it.
When you build a project you lock up the .DLL file in the project you build it from, because that is the version of the assembly that the library instance of visual studio will use - however you are referencing that very same library in another process hence the reason you are seeing the error.
You have two options, keep having two instances and then close the two instances open them again and it will be fine.
What you are better off doing is adding the project itself you are referencing (and are getting the error for) to your solution. Then instead of referencing YourProject/bin/debug/assembly.dll add a reference to the local project via the Projects tab. This will then keep one process referencing the appropriate assemblies that it needs.
For every project in the solution check the project settings -> Compile tab -> advanced compile options... -> target framework(all configurations), see if they are all (for example) .NET framework 4. having different or the wrong framework might cause the problems you're having right now
There are 5 console apps working off each other's outputs and are separately installed on my computer (C# 4.0, I am the author) . Management would like to distribute this suite of apps to other users, but aren't thrilled about asking non-tech users to install/configure 5 separate applications. Is there any way I can compile each program down into a .dll and reference them through a single master application?
Q. The main issue seems to be that you don't want 5 separate installation steps?
A. Make an installer for the suite :) Use any MSI builder (WiX, Visual Studio setup projects, InstallShield, and many others; Heck, you could even do an XCOPY deployment in most cases)
Q. How do I directly invoke these programs from within a single process?
A. Options:
Load the assemblies in your AppDomain.
Use a separate AppDomain in case of name(space) conflicts or version conflicts
Q. How do I optionally 'hide' the presence of the external console apps from view
A. Look at ilmerge to possibly combine the 'external' assemblies so they aren't visible anymore. If you can't use ilmerge (conflicts, or e.g. WPF apps) you might embed them as resources and load them on demand as per 1. and 2. above
Update: https://libz.codeplex.com/ is a nice looking project that makes this easy (haven't tried it myself)
Just because each of them is a separate .exe file doesn't mean you can't treat them as one application. And they don't have to be installed or configured separately either.
But a much better solution would be to rewrite each of the applications, so that they expose classes or interfaces that can be used without actually running the application. This way, communication between the parts is going to be much easier.
In .Net, the only difference between .exe and .dll is that you can run .exe directly. But you can treat both as libraries, so you can use functionality from one .exe in another .exe. Another step might be separating the core of each application into a .dll and make the .exes just deal with input and output. With this, the combined application wouldn't have all the code that it doesn't need from the other ones.
Its possible if every assembly is using different class names. Just include the whole source code when you compile the final version in one project.
Go to Project's properties, Application and change OutputType from Console to Class Library.
EDIT
Would like to express my doubts on architectual desicion like this, correct me if I'm wrong in my thinking:
Having different EXE applications standalone, I presume, you have different Applications that works standalone.
What advantage you gain by converting them in DLL's and puting them together in one master app ? Why do not just use this EXEs with one master app and launch them ?
In this way you leave as is it already working + you add a layer (master app) so for final user all this seems like one single app.
That is possible - several options:
you put the functionality of each console app into a separate class within the same project and have one "master console app" provide their functionalities
you put the functionality of each console app into a separate class each in different project with DLL as target, then you reference those DLLs as needed from your "master console app"
Note: IF you go the DLL route you could embed the DLLs into the console EXE using the technique from http://blogs.msdn.com/b/microsoft_press/archive/2010/02/03/jeffrey-richter-excerpt-2-from-clr-via-c-third-edition.aspx
With both option (all in one EXE or EXE + embedded DLLs) you can just make an XCOPY deployment if there are no other dependencies...
Have written all the code in a silverlight class library (dll) and linked this same library to my web app and silverlight app, is there a way to avoid the "Compiler Error Message: CS0433" or do I have to create a separate dll for the web app?
Error mostly occurs when XElement is called...
You need to create two projects, but can add the same CS file using Add Existing Item as a Link. http://msdn.microsoft.com/en-us/library/9f4t9t92.aspx explains it.
http://www.scip.be/index.php?Page=ArticlesNET28 is a nice read with related info.
Do you mean you are referencing a single dll from both the web app and the Silverlight app? I would have two versions of the dll (and two project files); one built for regular .NET (for use in the web app), and one for Silverlight; the main difference being the target framework and the references.
If you don't want to deal with having to maintain two project files (when you add classes etc), then you can use this trick to reduce this overhead.