I am a javascript/html developer that hasn't ventured into visual studio much, so this might be a trivial question.
I am currently developing a Windows Store app (winJS), that will likely turn into several apps. And it would be highly likely that I will be reusing code, so I have made a js library with the common code.
The question is, how can I develop on this lib in visual studio, so that the apps that I am developing will use the latest version of it (i.e without me having to copy the files in again manually).
Best thing I can think of is, create a new project for the lib, and include it in the applications solutions, but what type of project would it have to be, and how to you expose the files?
Hope that makes sense!
Thanks!
I usually solve this by having the project copy the JS files I want to a common location, and add that file to the target project using a LINK to the file I want to include, rather than just adding it -- this is on the "Add Existing File" dialog, under the little arrow on the "Add" button.
VS 2012 doesn't have a JavaScript library project type. You'll have to manage your library as loose files.
The easiest thing would probably be to create a nuget package. That way it would be easy to pull into other projects and have the tool help keep you up to date. It does have the downside of needing to put your stuff into a nuget feed, which is not something you want for private stuff.
Related
I have a class library dll that loads AutoCAD scripts from a network folder. However I need a way to ensure the class library can be updated silently. With Windows Form applications I would just use a ClickOnce Deployment and then use Application.Restart, however as this has to be a Class Library (as it is an AutoCAD addon) this doesn't seem to be possible.
What's the best way to handle this?
This is not possible with AutoCAD plugins because the DLL is loaded in the AppDomain. This 'silent' update is possible only with C++.
You can go the TDD way which is good practice. Here is a handout on the topic because TDD in AutoCAD is not that easy because of the above mentioned problem.
You can try to develop you algorithm in your own classes in order to have better TDD experience. Then transfer it with DTOs to AutoCADs transaction.
Some developers have 2 (or more) DLLs with AutoCAD code: the 1st main DLLs loads on AutoCAD startup, check for updates, download and install. The 2nd DLL actually contains the commands that will be demand loaded when the user run the command.
I recently built a solution that allows reloading the same copy of a .dll into AutoCAD.
Check out my blog with the full solution:
http://www.cadwiki.net/blogpost/How-to-reload-a-.dll-into-AutoCAD
I'm currently trying to compile an old program (made with C++ builder 2 or 3) with the "current" Embarcadero RAD Studio XE2.
So, I was wondering whether there is an easy way to use the old code, as Borland once claimed to be fully compatible to lower versions... however I couldn't find a "project-file", only source-code (.cpp, .h, .res, etc.).
I tried to "add to project" the main .cpp, however there seem to be some wrong include-paths... it also seem to use the OWL-package and includes its important source-files...
I'm a bit confused which type of main project I have to open first, since you need to open a new project before adding the source to it. As the running .exe has a GUI, I tried a Form-Window first, but it may be better to use a console or service as the real form is produced within the code as far as I understand.
So, after installing OWL and correcting the include-paths, do you think it should be running fine? Or is there something else to take care of?
If your old project was using OWL, you're probably well outside of the supported upgrade path.
That being said, valid C++ code should still compile and work and I've heard of people using OWL with recent versions of C++Builder. (via OWLNext)
Regarding your confusion as to which type of project to use, I believe a console application would be your best bet. A forms application is completely wrong, that will bring in the VCL and give you no end of problems trying to reconcile the different windowing systems. A service application is a completely different beast as well, and isn't meant for GUI applications. A console application should work, but you'll need more. The OWLNext project has a wiki that should help quite a bit.
I come from a Mac background. I developed games with Xcode and Objective-C frameworks.
Recently I moved to Windows and decided to use VB.NET for a while. It is cool.
Here is my intention:
I want to develop a Windows platform game. The game is rather complex, and I will need some kind of "engine" or "editor" to be able to edit my levels and properties easily. The idea is that I can build most of the game with this editor and then the editor will compile the project files and resources into one .exe file for gaming.
Fortunately, I was able to create my editor with VB.NET. I am able to edit levels and such. However, I am not sure about the "compilation" part to create a .exe file and play the game.
Basically I am at the point of designing the "Compile" button in my editor. But I am clueless. I could not find much documentation regarding this topic.
My editor has all variables and information the game needs to run.
I assume that this .exe file is like another VB.NET project (produced by my editor) that will basically take the data it comes with and "run" the game loop alright.
Any ideas, links, etc? Thanks.
**Note: my game is a 2d game with, probably, a vast amount of sprites and such.
Visual Studio is a fantastic IDE for development of Windows apps. Compiling the project is pretty simple. You just compile and it gives you an exe that's in the .NET Framework. Microsoft also has XNA Game Studio to help with game design if you want to look at gaming frameworks for .NET.
Also, you can take files from your editor if they generate vb.net and use the vbc compiler command to compile them into libraries, executables, whatever you like. The command could be something like this:
vbc /reference:Microsoft.VisualBasic.dll File.vb
Here's a link to the .NET command line compiler for VB.NET.
I'm not entirely sure what you mean here. Are you saying that you have an editor (something like a level or map editor?) for your game, and that you want the output of this editor to be embedded into the exe for your actual game application when it compiles?
If that's the case (or something similar to it) then you'll first want to consider how to persist your data to file. Then you could manually add files you've created as embedded resources. Or better yet, create a file type that holds as many 'levels' or 'maps' as you need and embed that. This way as you create more they will just get added to that file and you won't have to keep adding more embedded resources.
When using Wix/Votive to create setup projects with Visual Studio integration, it seems like COM registration is a big hole in the feature set. Both Visual Studio and the integrated Visual Studio setup projects do this almost effortlessly. Wix, on the other hand, makes it positively painful.
During the build process, Votive calls Heat.exe to harvest referenced projects. Why could it not at that point also harvest the registry entries necessary for COM Interop? This would integrate the process into the build and free up developers from this mind-deadening chore. It would also maintain a declarative/data-driven install process.
Has anyone looked into doing something like this? I imagine it would be necessary to edit some of the Wix MSBuild targets, I'm not confident enough with MSbuild to do it myself. I'd be really interested to hear from anyone who's had a stab at it though.
I don't believe in dynamically generating components during the build. I've written entire articles on the fragility and non-deterministic behavior of that pattern. Instead I treat my installer source just like the rest of the system and author it up front and check it in for the build to merely compile.
In that situation I use heat to generate the registry data for my COM/COM Visible dll's. Being lazy, I wrote a tiny winforms utility that puts a filesystem watcher on a dirctory and whenever there is a change notification I pass the directory off to heat. I then get heat's output and load it into the winform using an XML editor to provide highlighting. I look at what it wrote and if I like it I copy and paste it into my wxs files.
Updated with URL upon request:
Dealing with very large number of files
I have a working Windows Forms app (split into an EXE and a few DLLs). Now I've been asked to look at creating another app (MyAppLite) that has only a very small subset of the functionality. Think of it as similar to MS Word Viewer vs. MS Word.
Everything that I need to build MyAppLite is contained in the main solution - essentially I need to use a couple of the WinForms and whatever bits in the DLLs they call into.
What would be the best way to do this?
I was thinking of creating another Project in my solution for MyAppLite, then adding the necessary source files as links (using Add Existing Item > Add As Link in Solution Explorer).
I definitely wouldn't want to maintain 2 copies of the source code.
FYI it's a .NET 2.0 VB app, using VS2008.
You can create a new class library to contain your forms that are common to both projects. Create the new project and copy the forms from the original project into the new class library. Then you can import the class library into both the original project (after removing the original versions of the forms) and the MyAppLite version. If you need to change the forms, change it in the class library and then recompile your applications
You could refactor your project so that it would keep the common functionality in a MyAppCore project, and reference that from both MyApp and MyAppLite. The core dll would contain all the common functionality and take parameters as to what to allow and what to restrict, so the set of features in your lite version is customizable(say you have a customer that reaaaallly wants a preview of a certain feature).